From 6dee65974da67b61a6e5a52c0caaee0ffd1fc46d Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 15 Dec 2022 15:43:45 +0900 Subject: [PATCH 01/69] [ko] Update outdated files in dev-1.26-ko.1 R1-3 --- .../reference/instrumentation/node-metrics.md | 55 ++++++++++++ .../{ => networking}/ports-and-protocols.md | 2 +- content/ko/docs/reference/node/_index.md | 14 ++- .../kubelet-credential-provider.md | 86 ++++++++++--------- .../resource-metrics-pipeline.md | 27 +----- .../services}/connect-applications-service.md | 31 ++++--- 6 files changed, 135 insertions(+), 80 deletions(-) create mode 100644 content/ko/docs/reference/instrumentation/node-metrics.md rename content/ko/docs/reference/{ => networking}/ports-and-protocols.md (99%) rename content/ko/docs/tasks/{kubelet-credential-provider => administer-cluster}/kubelet-credential-provider.md (58%) rename content/ko/docs/{concepts/services-networking => tutorials/services}/connect-applications-service.md (93%) diff --git a/content/ko/docs/reference/instrumentation/node-metrics.md b/content/ko/docs/reference/instrumentation/node-metrics.md new file mode 100644 index 0000000000..78a3812346 --- /dev/null +++ b/content/ko/docs/reference/instrumentation/node-metrics.md @@ -0,0 +1,55 @@ +--- +title: 노드 메트릭 데이터 +content_type: reference +weight: 50 +description: >- + 노드, 볼륨, 파드, 컨테이너 레벨에서 + kubelet이 보는 것과 동일한 메트릭에 접근하는 메커니즘 +--- + +[kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 +노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며, +이 통계를 +[요약 API(Summary API)](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다. + +통계 요약 API에 대한 요청을 +쿠버네티스 API 서버를 통해 프록시하여 전송할 수 있다. + +다음은 `minikube`라는 이름의 노드에 대한 요약 API 요청 예시이다. + +```shell +kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" +``` + +다음은 `curl`을 이용하여 동일한 API 호출을 하는 명령어다. + +```shell +# 먼저 "kubectl proxy"를 실행해야 한다. +# 8080 부분을 "kubectl proxy" 명령이 할당해 준 포트로 치환한다. +curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary +``` + +{{< note >}} +`metrics-server` 0.6.x 버전부터, `metrics-server`는 `/stats/summary`가 아닌 +`/metrics/resource` kubelet 엔드포인트에 대해 질의한다. +{{< /note >}} + +## 요약 메트릭 API 소스 {#summary-api-source} + +기본적으로, 쿠버네티스는 kubelet 내부에서 실행되는 +내장 [cAdvisor](https://github.com/google/cadvisor)를 사용하여 노드 요약 메트릭 데이터를 가져온다. + +## CRI를 통해 요약 API 데이터 가져오기 {#pod-and-container-stats-from-cri} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +클러스터에 `PodAndContainerStatsFromCRI` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고, +{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스(CRI)">}}를 +통한 통계 정보 접근을 지원하는 컨테이너 런타임을 사용하는 경우, +kubelet은 cAdvisor가 아닌 CRI를 사용하여 파드 및 컨테이너 수준의 메트릭 데이터를 가져온다. + +## {{% heading "whatsnext" %}} + +[클러스터 트러블슈팅하기](/ko/docs/tasks/debug/debug-cluster/) 태스크 페이지에서 +이러한 데이터에 의존하는 메트릭 파이프라인을 사용하는 방법에 대해 다룬다. diff --git a/content/ko/docs/reference/ports-and-protocols.md b/content/ko/docs/reference/networking/ports-and-protocols.md similarity index 99% rename from content/ko/docs/reference/ports-and-protocols.md rename to content/ko/docs/reference/networking/ports-and-protocols.md index 6ba447cda9..d86f035419 100644 --- a/content/ko/docs/reference/ports-and-protocols.md +++ b/content/ko/docs/reference/networking/ports-and-protocols.md @@ -1,7 +1,7 @@ --- title: 포트와 프로토콜 content_type: reference -weight: 50 +weight: 40 --- 물리적 네트워크 방화벽이 있는 온프레미스 데이터 센터 또는 diff --git a/content/ko/docs/reference/node/_index.md b/content/ko/docs/reference/node/_index.md index 83bdb046b1..50822eb357 100644 --- a/content/ko/docs/reference/node/_index.md +++ b/content/ko/docs/reference/node/_index.md @@ -1,4 +1,16 @@ --- title: 노드 레퍼런스 정보 -weight: 40 +weight: 80 +no_list: true --- + +이 섹션에서는 노드에 관한 다음의 레퍼런스 주제를 다룬다. + +* kubelet의 [체크포인트 API](/docs/reference/node/kubelet-checkpoint-api/) +* [도커심 제거 및 CRI 호환 런타임 사용에 대한 글](/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) 목록 + +다음과 같은 다른 쿠버네티스 문서에서도 +노드 레퍼런스 상세에 대해 읽어볼 수 있다. + +* [노드 메트릭 데이터](/ko/docs/reference/instrumentation/node-metrics/). + diff --git a/content/ko/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md b/content/ko/docs/tasks/administer-cluster/kubelet-credential-provider.md similarity index 58% rename from content/ko/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md rename to content/ko/docs/tasks/administer-cluster/kubelet-credential-provider.md index 10911e48f7..29cd287a0f 100644 --- a/content/ko/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md +++ b/content/ko/docs/tasks/administer-cluster/kubelet-credential-provider.md @@ -5,9 +5,10 @@ title: kubelet 이미지 자격 증명 공급자 구성하기 # - cheftako description: kubelet의 이미지 자격 증명 공급자 플러그인을 구성한다. content_type: task +min-kubernetes-server-version: v1.26 --- -{{< feature-state for_k8s_version="v1.24" state="beta" >}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} @@ -27,10 +28,13 @@ kubelet은 플러그인을 통해 정적 자격 증명을 디스크에 저장하 ## {{% heading "prerequisites" %}} -* kubelet 이미지 자격 증명 공급자는 알파(alpha) 기능으로 v1.20에서 도입되었다. - 이 기능을 구동하려면, 다른 알파 기능과 마찬가지로 기능 게이트(feature gate) `KubeletCredentialProviders`가 kubelet에서만 활성화되어야 한다. +* kubelet 자격 증명 공급자 플러그인을 지원하는 노드로 구성된 쿠버네티스 클러스터가 필요하다. + 이 기능은 쿠버네티스 {{< skew currentVersion >}}에서 사용 가능하다. + 쿠버네티스 v1.24 및 v1.25에는 베타 기능으로 포함되었으며, 기본적으로 활성화되어 있다. * 자격 증명 공급자 exec 플러그인에 대한 구현체(implementation)가 필요하다. 이를 위해 자체 플러그인을 구축하거나 클라우드 공급자가 제공하는 플러그인을 사용할 수 있다. +{{< version-check >}} + ## 노드에 플러그인 설치하기 @@ -52,36 +56,36 @@ kubelet은 `--image-credential-provider-config`로 전달된 구성 파일을 [ECR](https://aws.amazon.com/ecr/)-based 플러그인을 사용하는 경우 사용하게 될 수 있는 구성 파일의 예: ```yaml -apiVersion: kubelet.config.k8s.io/v1alpha1 +apiVersion: kubelet.config.k8s.io/v1 kind: CredentialProviderConfig -# providers is a list of credential provider plugins that will be enabled by the kubelet. -# Multiple providers may match against a single image, in which case credentials -# from all providers will be returned to the kubelet. If multiple providers are called -# for a single image, the results are combined. If providers return overlapping -# auth keys, the value from the provider earlier in this list is used. +# providers 필드는 kubelet이 활성화할 자격 증명 공급자 헬퍼 플러그인의 목록을 나타낸다. +# 단일 이미지에 대해 복수 공급자가 매치될 수도 있으며, +# 이러한 경우 모든 공급자의 자격 증명이 kubelet으로 리턴된다. +# 단일 이미지에 대해 복수 공급자가 호출된 경우, 결과가 합산된다. +# 공급자가 중복되는(overlapping) 인증 키를 리턴한 경우, 이 목록의 위쪽에 위치하는 공급자로부터의 값이 사용된다. providers: - # name is the required name of the credential provider. It must match the name of the - # provider executable as seen by the kubelet. The executable must be in the kubelet's - # bin directory (set by the --image-credential-provider-bin-dir flag). + # name 필드는 자격 증명 공급자를 구분하기 위한 필수 필드이다. + # 이 이름은 kubelet이 인식하는 공급자 실행 파일의 이름과 일치해야 한다. + # 해당 실행 파일은 kubelet의 bin 디렉토리에 존재해야 한다(--image-credential-provider-bin-dir 플래그로 설정). - name: ecr - # matchImages is a required list of strings used to match against images in order to - # determine if this provider should be invoked. If one of the strings matches the - # requested image from the kubelet, the plugin will be invoked and given a chance - # to provide credentials. Images are expected to contain the registry domain - # and URL path. + # matchImages 필드는 각 이미지에 대해 이 공급자가 활성화되어야 하는지를 + # 판단하기 위한 문자열의 목록을 나타내는 필수 필드이다. + # kubelet이 요청한 이미지가 다음 문자열 중 하나와 매치되면, + # 해당 플러그인이 활성화되어 자격 증명을 제공할 수 있게 된다. + # 이미지 태그 문자열은 저장소(registry) 도메인 및 URL 경로를 포함해야 한다. # - # Each entry in matchImages is a pattern which can optionally contain a port and a path. - # Globs can be used in the domain, but not in the port or the path. Globs are supported - # as subdomains like '*.k8s.io' or 'k8s.*.io', and top-level-domains such as 'k8s.*'. - # Matching partial subdomains like 'app*.k8s.io' is also supported. Each glob can only match - # a single subdomain segment, so *.io does not match *.k8s.io. + # matchImages의 각 항목은 패턴을 나타내며, 포트와 경로를 포함할 수 있다. + # 도메인 자리에 글롭(glob)도 사용할 수 있으나, 포트와 경로에는 사용할 수 없다. + # 글롭은 '*.k8s.io' 또는 'k8s.*.io'와 같이 서브도메인 형태로 사용하거나, 'k8s.*'와 같이 최상위 도메인 형태로 사용할 수 있다. + # 'app*.k8s.io'와 같이 서브도메인의 일부를 매칭하는 것도 지원된다. + # 각 글롭은 단일 서브도메인 분할만을 매칭할 수 있으므로, `*.io`는 `*.k8s.io`에 매치되지 **않는다**. # - # A match exists between an image and a matchImage when all of the below are true: - # - Both contain the same number of domain parts and each part matches. - # - The URL path of an imageMatch must be a prefix of the target image URL path. - # - If the imageMatch contains a port, then the port must match in the image as well. + # 다음 사항이 모두 만족될 때에만 image와 matchImage가 매치되었다고 판단한다. + # - 양쪽의 도메인 파트 수가 동일하고, 각 파트가 매치됨 + # - imageMatch의 URL 경로가 타겟 이미지 URL 경로의 접두사임 + # - imageMatch가 포트를 포함하면, 이미지 쪽에 기재된 포트와 매치됨 # - # Example values of matchImages: + # matchImages 예시는 다음과 같다. # - 123456789.dkr.ecr.us-east-1.amazonaws.com # - *.azurecr.io # - gcr.io @@ -93,21 +97,21 @@ providers: - "*.dkr.ecr-fips.*.amazonaws.com" - "*.dkr.ecr.us-iso-east-1.c2s.ic.gov" - "*.dkr.ecr.us-isob-east-1.sc2s.sgov.gov" - # defaultCacheDuration is the default duration the plugin will cache credentials in-memory - # if a cache duration is not provided in the plugin response. This field is required. + # defaultCacheDuration 필드는 캐시 기간이 플러그인 응답에 명시되지 않은 경우에 + # 해당 플러그인이 자격 증명을 인메모리 캐시에 보관할 기본 기간을 지정한다. 이 필드는 필수이다. defaultCacheDuration: "12h" - # Required input version of the exec CredentialProviderRequest. The returned CredentialProviderResponse - # MUST use the same encoding version as the input. Current supported values are: - # - credentialprovider.kubelet.k8s.io/v1alpha1 - apiVersion: credentialprovider.kubelet.k8s.io/v1alpha1 - # Arguments to pass to the command when executing it. - # +optional + # apiVersion 필드는 CredentialProviderRequest를 실행할 때 기재될 입력 버전을 지정하는 필수 필드이다. + # 응답 CredentialProviderResponse는 입력과 동일한 인코딩 버전을 사용해야 한다. 현재 지원되는 값은 다음과 같다. + # - credentialprovider.kubelet.k8s.io/v1 + apiVersion: credentialprovider.kubelet.k8s.io/v1 + # args 필드는 커맨드를 실행할 때 전달할 인자를 지정하는 필드이다. + # 이 필드는 선택사항이다. args: - get-credentials - # Env defines additional environment variables to expose to the process. These - # are unioned with the host's environment, as well as variables client-go uses - # to pass argument to the plugin. - # +optional + # env 필드는 프로세스에 노출할 추가적인 환경 변수를 기재하는 필드이다. + # 이들은 호스트의 환경 변수 및 + # client-go가 플러그인에 인자를 전달하기 위해 사용하는 변수와 합산된다. + # 이 필드는 선택사항이다. env: - name: AWS_PROFILE value: example_profile @@ -150,7 +154,7 @@ Glob은 `*.k8s.io`이나 `k8s.*.io` 같은 서브도메인과 `k8s.*`와 같은 ## {{% heading "whatsnext" %}} -* [kubelet 구성 API(v1alpha1) 레퍼런스](/docs/reference/config-api/kubelet-config.v1alpha1/)에서 +* [kubelet 구성 API(v1) 레퍼런스](/docs/reference/config-api/kubelet-config.v1/)에서 `CredentialProviderConfig`에 대한 세부 정보 읽기 -* [kubelet 자격 증명 공급자 API (v1alpha1) 레퍼런스](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) 읽기 +* [kubelet 자격 증명 공급자 API (v1) 레퍼런스](/docs/reference/config-api/kubelet-credentialprovider.v1/) 읽기 diff --git a/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md index 0e69c8eb46..c7f484c79b 100644 --- a/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md @@ -232,6 +232,8 @@ metrics-server는 각 노드로부터 메트릭을 수집하기 위해 [kubelet] * v0.6.0 이상: 메트릭 리소스 엔드포인트 `/metrics/resource` * 이전 버전: 요약 API 엔드포인트 `/stats/summary` +## {{% heading "whatsnext" %}} + metrics-server에 대한 더 많은 정보는 [metrics-server 저장소](https://github.com/kubernetes-sigs/metrics-server)를 확인한다. @@ -243,26 +245,5 @@ metrics-server에 대한 더 많은 정보는 * [metrics-server 릴리스](https://github.com/kubernetes-sigs/metrics-server/releases) * [Horizontal Pod Autoscaling](/ko/docs/tasks/run-application/horizontal-pod-autoscale/) -### 요약 API(Summary API) 소스 {#summary-api-source} - -[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 -노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며, -소비자(consumer)가 읽을 수 있도록 이 통계를 -[요약 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다. - -다음은 `minikube` 노드에 대한 요약 API 요청 예시이다. - -```shell -kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" -``` - -다음은 `curl`을 이용하여 동일한 API 호출을 하는 명령어다. - -```shell -curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary -``` - -{{< note >}} -metrics-server 0.6.x 버전부터, -요약 API `/stats/summary` 엔드포인트가 `/metrics/resource` 엔드포인트로 대체될 것이다. -{{< /note >}} +kubelet이 어떻게 노드 메트릭을 제공하는지, 그리고 쿠버네티스 API를 통해 이러한 메트릭에 어떻게 접근하는지 알아보려면, +[노드 메트릭 데이터](/ko/docs/reference/instrumentation/node-metrics/) 문서를 참조한다. diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/tutorials/services/connect-applications-service.md similarity index 93% rename from content/ko/docs/concepts/services-networking/connect-applications-service.md rename to content/ko/docs/tutorials/services/connect-applications-service.md index b0afada7b7..b1c904fefe 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/tutorials/services/connect-applications-service.md @@ -4,8 +4,8 @@ # - lavalamp # - thockin title: 서비스와 애플리케이션 연결하기 -content_type: concept -weight: 30 +content_type: tutorial +weight: 20 --- @@ -17,9 +17,7 @@ weight: 30 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트(localhost)에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다. -이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. - - +이 튜토리얼은 간단한 nginx 서버를 사용하여 개념을 시연한다. @@ -53,11 +51,12 @@ kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs 이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다. + 만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다. ## 서비스 생성하기 -평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다. +이제 우리에게는 플랫(flat)하고 클러스터 전역에 걸치는 주소 공간에서 실행되고 있는 nginx 파드가 있다. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 해결하는 것이 바로 서비스이다. 쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다. @@ -91,13 +90,17 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx ClusterIP 10.0.162.149 80/TCP 21s ``` -앞에서 언급한 바와 같이, 서비스는 파드 그룹에 의해 지원된다. 이 파드들은 -`endpoints` 를 통해 노출된다. 서비스 셀렉터는 지속적으로 평가되고 -결과는 `my-nginx` 이름의 엔드포인트 오브젝트에 POST된다. -파드가 죽으면 자동적으로 엔드포인트에서 제거되며 서비스 셀렉터와 -일치하는 새 파드는 자동적으로 엔드포인트에 추가된다. -엔드포인트를 확인하고 IP가 첫 번째 단계에서 생성된 파드와 동일하다는 -점을 참고한다. +앞에서 언급한 바와 같이, 서비스 밑에는 여러 파드들이 있다. +이 파드들은 +{{}}를 +통해 노출된다. 해당 서비스의 셀렉터는 지속적으로 평가되고, 그 결과는 +{{< glossary_tooltip text="레이블" term_id="label" >}}을 사용하여 +서비스에 연결된 엔드포인트슬라이스로 POST된다. +파드가 죽으면, 해당 파드를 엔드포인트로 갖는 엔드포인트슬라이스에서 자동으로 제거된다. +신규 파드가 특정 서비스의 셀렉터에 매치되면 +해당 서비스를 위한 엔드포인트슬라이스에 자동으로 추가된다. +엔드포인트를 확인해 보면, +IP가 첫 번째 단계에서 생성된 파드의 IP와 동일하다는 것을 알 수 있다. ```shell kubectl describe svc my-nginx @@ -140,7 +143,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외 {{< /note >}} -### 환경 변수들 +### 환경 변수 파드가 노드에서 실행될 때 kubelet은 각기 활성화된 서비스에 대해 일련의 환경 변수 집합을 추가한다. 이것은 순서 문제를 야기한다. 이유를 확인하려면 From 22245ca14d9ac6c9e4adda4d51fc89a4926f5703 Mon Sep 17 00:00:00 2001 From: Jesang Myung Date: Tue, 20 Dec 2022 21:41:38 +0900 Subject: [PATCH 02/69] Update dns-pod-service.md Change kubelet from plural to singular following origin document. --- content/ko/docs/concepts/services-networking/dns-pod-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 760505b3c6..267f8a1e3b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -17,7 +17,7 @@ weight: 20 쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, 개별 컨테이너들이 DNS 네임을 해석할 때 -DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. +DNS 서비스의 IP를 사용하도록 kubelet을 구성한다. 클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. 기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 From deeee13691903b5171f5cc985fee8994a6fefd66 Mon Sep 17 00:00:00 2001 From: Jaeo Date: Mon, 16 Jan 2023 14:20:33 +0900 Subject: [PATCH 03/69] [ko] update outdated files in dev-1.26-ko.1 (M7) --- content/ko/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index ce2f0eab36..897e1fd51c 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -456,7 +456,7 @@ Message: Pod was terminated in response to imminent node shutdown. ## 논 그레이스풀 노드 셧다운 {#non-graceful-node-shutdown} -{{< feature-state state="alpha" for_k8s_version="v1.24" >}} +{{< feature-state state="beta" for_k8s_version="v1.26" >}} 전달한 명령이 kubelet에서 사용하는 금지 잠금 메커니즘(inhibitor locks mechanism)을 트리거하지 않거나, 또는 사용자 오류(예: ShutdownGracePeriod 및 ShutdownGracePeriodCriticalPods가 제대로 설정되지 않음)로 인해 From 55efb5fdff2a5a43342f4d66c2ca3ec9aee6933a Mon Sep 17 00:00:00 2001 From: iro Date: Tue, 17 Jan 2023 22:12:21 +0900 Subject: [PATCH 04/69] Fix typo, It should be modified to 'replicas: 3' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 'website/content/ko/examples/service/access/backend-deployment.yaml' different from 'website/content/en/examples/service/access/backend-deployment.yaml' It should be modified to 3 depending on the context. 첫 pull request 로 일전에 main 에서 분기하여 main 에 병합요청 넣었던 것을 바로 잡아주셔서 감사합니다 😂 --- content/ko/examples/service/access/backend-deployment.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/examples/service/access/backend-deployment.yaml b/content/ko/examples/service/access/backend-deployment.yaml index 85dff18ee1..19696908f1 100644 --- a/content/ko/examples/service/access/backend-deployment.yaml +++ b/content/ko/examples/service/access/backend-deployment.yaml @@ -8,7 +8,7 @@ spec: app: hello tier: backend track: stable - replicas: 7 + replicas: 3 template: metadata: labels: From 1c1999fef2826501d9a053868d4647651df35cd4 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Tue, 6 Dec 2022 19:17:09 +0900 Subject: [PATCH 05/69] [ko] Tranlsate run-replicated-stateful-application.md into Korean --- .../run-replicated-stateful-application.md | 548 ++++++++++++++++++ 1 file changed, 548 insertions(+) create mode 100644 content/ko/docs/tasks/run-application/run-replicated-stateful-application.md diff --git a/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md new file mode 100644 index 0000000000..ed38bbb053 --- /dev/null +++ b/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md @@ -0,0 +1,548 @@ +--- +# reviewers: +# - enisoc +# - erictune +# - foxish +# - janetkuo +# - kow3ns +# - smarterclayton +title: 복제 스테이트풀 애플리케이션 실행하기 +content_type: tutorial +weight: 30 +--- + + + +이 페이지에서는 {{< glossary_tooltip term_id="statefulset" >}} 으로 복제 +스테이트풀 애플리케이션을 실행하는 방법에 대해 소개한다. +이 애플리케이션은 복제 MySQL 데이터베이스이다. 이 예제의 토폴로지는 +단일 주 서버와 여러 복제 서버로 이루어져있으며, row-based 비동기 복제 방식을 +사용한다. + +{{< note >}} +**해당 설정은 프로덕션 설정이 아니다**. 쿠버네티스에서 스테이트풀한 애플리케이션을 실행하기 위한 일반적인 패턴에 +집중하기 위해 MySQL 세팅이 안전하지 않은 기본 설정으로 되어 있다. +{{< /note >}} + +## {{% heading "prerequisites" %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "default-storage-class-prereqs.md" >}} +* 이 튜토리얼은 + [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/) + 그리고 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/), + [파드](/ko/docs/concepts/workloads/pods/), + [서비스](/ko/docs/concepts/services-networking/service/), + [컨피그맵(ConfigMap)](/docs/tasks/configure-pod-container/configure-pod-configmap/)와 같은 핵심 개념들에 대해 알고 있다고 가정한다. +* MySQL에 대한 지식이 있으면 도움이 되지만, 이 튜토리얼은 다른 시스템을 활용하였을 때도 + 도움이 되는 일반적인 패턴을 다루는데 중점을 둔다. +* default 네임스페이스를 사용하거나, 다른 오브젝트들과 충돌이 나지 않는 다른 네임스페이스를 사용한다. + + + +## {{% heading "objectives" %}} + + +* 스테이트풀셋을 이용한 복제 MySQL 토폴로지를 배포한다. +* MySQL 클라이언트에게 트래픽을 보낸다. +* 다운타임에 대한 저항력을 관찰한다. +* 스테이트풀셋을 확장/축소한다. + + + + + +## MySQL 배포하기 + +MySQL 디플로이먼트 예시는 컨피그맵과, 2개의 서비스, 그리고 스테이트풀셋으로 +구성되어 있다. + +### 컨피그맵 생성하기 {#configmap} + +다음 YAML 설정 파일로부터 컨피그맵을 생성한다. + +{{< codenew file="application/mysql/mysql-configmap.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml +``` + +이 컨피그맵은 당신이 독립적으로 주 MySQL 서버와 레플리카들의 설정을 컨트롤할 수 있도록 +`my.cnf` 을 오버라이드한다. +이 경우에는, 주 서버는 복제 로그를 레플리카들에게 제공하고 +레플리카들은 복제를 통한 쓰기가 아닌 다른 쓰기들은 거부하도록 할 것이다. + +컨피그맵 자체가 다른 파드들에 서로 다른 설정 영역이 +적용되도록 하는 것이 아니다. +스테이트풀셋 컨트롤러가 제공해주는 정보에 따라서, +각 파드들은 초기화되면서 설정 영역을 참조할지 결정한다. + +### 서비스 생성하기 {#services} + +다음 YAML 설정 파일로부터 서비스를 생성한다. + +{{< codenew file="application/mysql/mysql-services.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml +``` + +헤드리스 서비스는 스테이트풀셋 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}가 집합의 일부분인 +파드들을 위해 생성한 DNS 엔트리들(entries)의 위한 거점이 된다. +헤드리스 서비스의 이름이 `mysql`이므로, 파드들은 +같은 쿠버네티스 클러스터나 네임스페이스에 존재하는 다른 파드들에게 `.mysql`라는 이름으로 +접근될 수 있다. + +`mysql-read`라고 불리우는 클라이언트 서비스는 고유의 클러스터 IP를 가지며, +Ready 상태인 모든 MySQL 파드들에게 커넥션을 분배하는 일반적인 서비스이다. +잠재적인 엔드포인트들의 집합은 주 MySQL 서버와 해당 +레플리카들을 포함한다. + +오직 읽기 쿼리들만 로드-밸런싱된 클라이언트 서비스를 이용할 수 있다는 사실에 주목하자. +하나의 주 MySQL 서버만이 존재하기 떄문에, 클라이언트들은 쓰기 작업을 실행하기 위해서 +주 MySQL 파드에 (헤드리스 서비스 안에 존재하는 DNS 엔트리를 통해) +직접 접근해야 한다. + +### 스테이트풀셋 생성하기 {#statefulset} + +마지막으로, 다음 YAML 설정 파일로부터 스테이트풀셋을 생성한다. + +{{< codenew file="application/mysql/mysql-statefulset.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml +``` + +다음을 실행하여, 초기화되는 프로세스들을 확인할 수 있다. + +```shell +kubectl get pods -l app=mysql --watch +``` + +잠시 뒤에, 3개의 파드들이 `Running` 상태가 되는 것을 볼 수 있다. + +``` +NAME READY STATUS RESTARTS AGE +mysql-0 2/2 Running 0 2m +mysql-1 2/2 Running 0 1m +mysql-2 2/2 Running 0 1m +``` + +**Ctrl+C**를 입력하여 watch를 종료하자. + +{{< note >}} +만약 아무 진행 상황도 보이지 않는다면, [시작하기 전에](#before-you-begin) 에 언급된 +동적 퍼시스턴트볼륨 프로비저너(provisioner)가 활성화되어 있는지 확인한다. +{{< /note >}} + +해당 메니페스트에는 스테이트풀셋의 일부분인 스테이트풀 파드들을 관리하기 위한 다양한 기법들이 +적용되어 있다. 다음 섹션에서는 스테트풀셋이 파드들을 생성할 때 일어나는 일들을 이해할 수 있도록 +일부 기법들을 강조하여 설명한다. + +## 스테이트풀 파드 초기화 이해하기 + +스테이트풀셋 컨트롤러는 파드들의 인덱스에 따라 +순차적으로 시작시킨다. +컨트롤러는 다음 파드 생성 이전에 각 파드가 Ready 상태가 되었다고 알려줄 때까지 기다린다. + +추가적으로, 컨트롤러는 각 파드들에게 `<스테이트풀셋 이름>-<순차적 인덱스>` 형태의 +고유하고 안정적인 이름을 부여하는데, 결과적으로 파드들은 `mysql-0`, `mysql-1`, +그리고 `mysql-2` 라는 이름을 가지게 된다. + +스테이트풀셋 매니페스트의 파드 템플릿은 해당 속성들을 통해 +순차적인 MySQL 복제의 시작을 수행한다. + +### 설정 생성하기 + +파드 스펙의 컨테이너를 시작하기 전에, 파드는 순서가 정의되어 있는 +[초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)들을 +먼저 실행시킨다. + +`init-mysql`라는 이름의 첫 번째 초기화 컨테이너는, 인덱스에 따라 +특별한 MySQL 설정 파일을 생성한다. + +스크립트는 인덱스를 `hostname` 명령으로 반환되는 파드 이름의 +마지막 부분에서 추출하여 결정한다. +그리고 인덱스(이미 사용된 값들을 피하기 위한 오프셋 숫자와 함께)를 +MySQL의 `conf.d` 디렉토리의 `server-id.cnf` 파일에 저장한다. +이는 스테이트풀셋에게서 제공된 고유하고, 안정적인 신원을 같은 속성을 +필요로 하는 MySQL 서버 ID의 형태로 바꾸어준다. + +또한 `init-mysql` 컨테이너의 스크립트는 컨피그맵을 `conf.d`로 복사하여, +`primary.cnf` 또는 `replica.cnf`을 적용한다. +이 예제의 토폴로지가 하나의 주 MySQL 서버와 일정 수의 레플리카들로 이루어져 있기 때문에, +스크립트는 `0` 인덱스를 주 서버로, 그리고 나머지 값들은 +레플리카로 지정한다. +스테이트풀셋 컨트롤러의 +[디플로이먼트와 스케일링 보증](/ko/docs/concepts/workloads/controllers/statefulset/#디플로이먼트와-스케일링-보증)과 +합쳐지면, 복제를 위한 레플리카들을 생성하기 전에 주 MySQL 서버가 Ready 상태가 되도록 +보장할 수 있다. + +### 기존 데이터 복제(cloning) + +일반적으로, 레플리카에 새로운 파드가 추가되는 경우, 주 MySQL 서버가 +이미 데이터를 가지고 있다고 가정해야 한다. 또한 복제 로그가 첫 시작점부터의 로그들을 +다 가지고 있지는 않을 수 있다고 가정해야 한다. +이러한 보수적인 가정들은 스테이트풀셋이 초기 크기로 고정되어 있는 것보다, 시간에 따라 +확장/축소하게 할 수 있도록 하는 중요한 열쇠가 된다. + +`clone-mysql`라는 이름의 두 번째 초기화 컨테이너는, 퍼시스턴트볼륨에서 처음 초기화된 +레플리카 파드에 복제 작업을 수행한다. +이 말은 다른 실행 중인 파드로부터 모든 데이터들을 복제하기 때문에, +로컬의 상태가 충분히 일관성을 유지하고 있어서 주 서버에서부터 복제를 시작할 수 있다는 의미이다. + +MySQL 자체가 이러한 메커니즘을 제공해주지는 않기 때문에, 이 예제에서는 XtraBackup이라는 +유명한 오픈소스 도구를 사용한다. +복제 중에는, 복제 대상 MySQL 서버가 성능 저하를 겪을 수 있다. +주 MySQL 서버의 이러한 충격을 최소화하기 위해, 스크립트는 각 파드가 자신의 인덱스보다 +하나 작은 파드로부터 복제하도록 지시한다. +이것이 정상적으로 동작하는 이유는 스테이트풀셋 컨트롤러가 파드 `N+1`을 실행하기 전에 +항상 파드 `N`이 Ready 상태라는 것을 보장하기 때문이다. + +### 복제(replication) 시작하기 + +초기화 컨테이너들의 성공적으로 완료되면, 일반적인 컨테이너가 실행된다. +MySQL 파드는 `mysqld` 서버를 구동하는 `mysql` 컨테이너로 구성되어 있으며, +`xtrabackup` 컨테이너는 +[사이드카(sidecar)](/blog/2015/06/the-distributed-system-toolkit-patterns)로서 작동한다. + +`xtrabackup` 사이드카는 복제된 데이터 파일들을 보고 레플리카에 MySQL 복제를 시작해야 할 +필요가 있는지 결정한다. +만약 그렇다면, `mysqld`이 준비될 때까지 기다린 후 `CHANGE MASTER TO`, +그리고 `START SLAVE`를 XtraBackup 복제(clone) 파일들에서 +추출한 복제(replication) 파라미터들과 함께 실행시킨다. + +레플리카가 복제를 시작하면, 먼저 주 MySQL 서버를 기억하고, 서버가 재시작되거나 +커넥션이 끊어지면 다시 연결한다. +또한 레플리카들은 주 서버를 안정된 DNS 이름 +(`mysql-0.mysql`)으로 찾기 때문에, 주 서버가 리스케쥴링에 의해 새로운 +파드 IP를 받아도 주 서버를 자동으로 찾는다. + +마지막으로, 복제를 시작한 후에는, `xtrabackup` 컨테이너는 데이터 복제를 요청하는 +다른 파드들의 커넥션을 리스닝한다. +이 서버는 스테이트풀셋이 확장하거나, 다음 파드가 퍼시스턴트볼륨클레임을 잃어서 다시 복제를 +수행해햐 할 경우를 대비하여 독립적으로 존재해야 한다. + +## 클라이언트 트래픽 보내기 + +임시 컨테이너를 `mysql:5.7` 이미지로 실행하고 `mysql` 클라이언트 +바이너리를 실행하는 것으로 테스트 쿼리를 주 MySQL 서버(`mysql-0.mysql` 호스트네임)로 +보낼 수 있다. + +```shell +kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\ + mysql -h mysql-0.mysql <`를 이전 단계에서 찾았던 노드의 이름으로 바꾸자. + +{{< caution >}} +노드 드레인은 해당 노드에서 실행 중인 다른 워크로드와 애플리케이션들에게 +영향을 줄 수 있다. 테스트 클러스터에만 +다음 단계를 수행하자. +{{< /caution >}} + +```shell +# 위에 명시된 다른 워크로드들이 받는 영향에 대한 주의사항을 확인한다. +kubectl drain --force --delete-emptydir-data --ignore-daemonsets +``` + +이제 파드가 다른 노드에 리스케줄링되는 것을 관찰할 수 있다. + +```shell +kubectl get pod mysql-2 -o wide --watch +``` + +출력은 다음과 비슷할 것이다. + +``` +NAME READY STATUS RESTARTS AGE IP NODE +mysql-2 2/2 Terminating 0 15m 10.244.1.56 kubernetes-node-9l2t +[...] +mysql-2 0/2 Pending 0 0s kubernetes-node-fjlm +mysql-2 0/2 Init:0/2 0 0s kubernetes-node-fjlm +mysql-2 0/2 Init:1/2 0 20s 10.244.5.32 kubernetes-node-fjlm +mysql-2 0/2 PodInitializing 0 21s 10.244.5.32 kubernetes-node-fjlm +mysql-2 1/2 Running 0 22s 10.244.5.32 kubernetes-node-fjlm +mysql-2 2/2 Running 0 30s 10.244.5.32 kubernetes-node-fjlm +``` + +그리고, 서버 ID `102`가 `SELECT @@server_id` 루프 출력에서 잠시 +사라진 후 다시 보이는 것을 확인할 수 있을 것이다. + +이제 노드의 스케줄 방지를 다시 해제(uncordon)해서 정상으로 돌아가도록 조치한다. + +```shell +kubectl uncordon +``` + +## 레플리카 스케일링하기 + +MySQL 레플리케이션을 사용하면, 레플리카를 추가하는 것으로 +읽기 쿼리 용량을 키울 수 있다. +스테이트풀셋을 사용하면, 단 한 줄의 명령으로 달성할 수 있다. + +```shell +kubectl scale statefulset mysql --replicas=5 +``` + +명령을 실행시켜서 새로운 파드들이 올라오는 것을 관찰하자. + +```shell +kubectl get pods -l app=mysql --watch +``` + +파드들이 올라오면, `SELECT @@server_id` 루프 출력에 서버 ID `103` 과 `104`가 나타나기 +시작할 것이다. + +그리고 해당 파드들이 존재하기 전에 추가된 데이터들이 해당 새 서버들에게도 존재하는 것을 +확인할 수 있다. + +```shell +kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\ + mysql -h mysql-3.mysql -e "SELECT * FROM test.messages" +``` + +``` +Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false ++---------+ +| message | ++---------+ +| hello | ++---------+ +pod "mysql-client" deleted +``` + +축소하는 것도 간단하게 할 수 있다. + +```shell +kubectl scale statefulset mysql --replicas=3 +``` + +{{< note >}} +확장은 퍼시스턴트볼륨클레임을 자동으로 생성하지만, +축소에서는 해당 PVC들이 자동으로 삭제되지 않는다. + +이로써 확장을 빠르게 하기 위해 초기화된 PVC들을 보관해 두거나, +삭제하기 전에 데이터를 추출하는 선택을 할 수 있다. +{{< /note >}} + +다음 명령을 실행하여 확인할 수 있다. + +```shell +kubectl get pvc -l app=mysql +``` + +스테이트풀셋을 3으로 축소했음에도 PVC 5개가 +아직 남아있음을 보여준다. + +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +data-mysql-0 Bound pvc-8acbf5dc-b103-11e6-93fa-42010a800002 10Gi RWO 20m +data-mysql-1 Bound pvc-8ad39820-b103-11e6-93fa-42010a800002 10Gi RWO 20m +data-mysql-2 Bound pvc-8ad69a6d-b103-11e6-93fa-42010a800002 10Gi RWO 20m +data-mysql-3 Bound pvc-50043c45-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m +data-mysql-4 Bound pvc-500a9957-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m +``` + +만약 여분의 PVC들을 재사용하지 않을 것이라면, 이들을 삭제할 수 있다. + +```shell +kubectl delete pvc data-mysql-3 +kubectl delete pvc data-mysql-4 +``` + + + +## {{% heading "cleanup" %}} + + +1. `SELECT @@server_id` 루프를 끝내기 위해, 터미널에 **Ctrl+C**를 입력하거나, + 해당 명령을 다른 터미널에서 실행시키자. + + ```shell + kubectl delete pod mysql-client-loop --now + ``` + +1. 스테이트풀셋을 삭제한다. 이것은 파드들 또한 삭제할 것이다. + + ```shell + kubectl delete statefulset mysql + ``` + +1. 파드들의 삭제를 확인한다. + 삭제가 완료되기까지 시간이 걸릴 수 있다. + + ```shell + kubectl get pods -l app=mysql + ``` + + 위와 같은 메세지가 나타나면 파드들이 삭제되었다는 것을 알 수 있다. + + ``` + No resources found. + ``` + +1. 컨피그맵, 서비스, 그리고 퍼시스턴트볼륨클레임들을 삭제한다. + + ```shell + kubectl delete configmap,service,pvc -l app=mysql + ``` + +1. 만약 수동으로 퍼시스턴스볼륨들을 프로비저닝했다면, 수동으로 삭제하면서, + 그 밑에 존재하는 리소스들을 또한 삭제해야 한다. + 만약 동적 프로비저너를 사용했다면, 당신이 퍼시스턴트볼륨클레임으로 삭제하면 + 자동으로 퍼시스턴트볼륨을 삭제한다. + 일부 (EBS나 PD와 같은) 동적 프로비저너들은 퍼시스턴트볼륨을 삭제 + 하면 그 뒤에 존재하는 리소스들도 삭제한다. + + + +## {{% heading "whatsnext" %}} + +* [스테이트풀셋(StatefulSet) 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 더 배워보기. +* [스테이트풀셋 디버깅하기](/ko/docs/tasks/debug/debug-application/debug-statefulset/)에 대해 더 배워보기. +* [스테이트풀셋(StatefulSet) 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)에 대해 더 배워보기. +* [스테이트풀셋(StatefulSet) 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 배워보기. +* [Helm Charts 저장소](https://artifacthub.io/)를 통해 + 다른 스테이트풀 애플리케이션 예제들을 확인해보기. From 0b9d4c324ee5099ef74fe4e2108b71ff6980487d Mon Sep 17 00:00:00 2001 From: jongwooo Date: Tue, 14 Feb 2023 00:56:53 +0900 Subject: [PATCH 06/69] [ko] Update outdated files in dev-1.26-ko.1 (M1) Signed-off-by: jongwooo --- content/ko/community/code-of-conduct.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/community/code-of-conduct.md b/content/ko/community/code-of-conduct.md index 77fe26b43a..99eba7aeb7 100644 --- a/content/ko/community/code-of-conduct.md +++ b/content/ko/community/code-of-conduct.md @@ -9,7 +9,7 @@ community_styles_migrated: true

쿠버네티스는 CNCF의 행동 강령을 따르고 있습니다. -커밋 71b12a2 +커밋 fff715fb0 에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다. 만약 최신 버전이 아닌 경우에는 이슈를 제기해 주세요. From 7410db4ec80e6463e93a560b04a64a5f8eed7d8b Mon Sep 17 00:00:00 2001 From: jongwooo Date: Wed, 15 Feb 2023 11:51:54 +0900 Subject: [PATCH 07/69] [ko] Update outdated files in dev-1.26-ko.1 (M3-M6) Signed-off-by: jongwooo --- content/ko/docs/concepts/architecture/cloud-controller.md | 2 +- content/ko/docs/concepts/architecture/cri.md | 2 +- content/ko/docs/concepts/architecture/garbage-collection.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index e8988cad16..68e13124ea 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -107,7 +107,7 @@ IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같 ### 서비스 컨트롤러 {#authorization-service-controller} -서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다. +서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다(엔드포인트슬라이스(EndpointSlice)의 경우, kube-controller-manager가 필요에 따라 이들을 관리한다). 서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다. diff --git a/content/ko/docs/concepts/architecture/cri.md b/content/ko/docs/concepts/architecture/cri.md index 34fd95ccd1..9af7dddb3a 100644 --- a/content/ko/docs/concepts/architecture/cri.md +++ b/content/ko/docs/concepts/architecture/cri.md @@ -1,7 +1,7 @@ --- title: 컨테이너 런타임 인터페이스(CRI) content_type: concept -weight: 50 +weight: 60 --- diff --git a/content/ko/docs/concepts/architecture/garbage-collection.md b/content/ko/docs/concepts/architecture/garbage-collection.md index 8b049bbd65..c4bd7a005a 100644 --- a/content/ko/docs/concepts/architecture/garbage-collection.md +++ b/content/ko/docs/concepts/architecture/garbage-collection.md @@ -1,7 +1,7 @@ --- title: 가비지(Garbage) 수집 content_type: concept -weight: 50 +weight: 70 --- From 32d457064a98c0b2759407258cbe48846b2eaebb Mon Sep 17 00:00:00 2001 From: Kim_ByungChul Date: Mon, 13 Feb 2023 22:23:54 +0900 Subject: [PATCH 08/69] [ko] Fix inappropriate translation It means exactly opposite, so I want to fix it Fix translation --- content/ko/docs/concepts/workloads/controllers/replicaset.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index b3b4d79ba4..9d22ae98f5 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -37,8 +37,8 @@ OwnerReference가 없거나, OwnerReference가 {{< glossary_tooltip term_id="con 레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다. 그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께 파드에 대한 선언적 업데이트를 제공하는 상위 개념이다. -따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 -레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다. +따라서 별도의 사용자 정의(custom) 업데이트 오케스트레이션이 필요한 경우 또는 업데이트가 전혀 필요 없는 경우가 아니라면, +레플리카셋을 직접 사용하기보다는 디플로이먼트를 사용하는 것을 권장한다. 이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다. 대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다. From a6e689f9da9a8ae7064a62bb97fedc8421c5f9d0 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Sun, 25 Dec 2022 22:53:34 +0900 Subject: [PATCH 09/69] [ko] Translate tasks-translate-compose-kubernetes.md into Korean --- .../translate-compose-kubernetes.md | 488 ++++++++++++++++++ 1 file changed, 488 insertions(+) create mode 100644 content/ko/docs/tasks/configure-pod-container/translate-compose-kubernetes.md diff --git a/content/ko/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/ko/docs/tasks/configure-pod-container/translate-compose-kubernetes.md new file mode 100644 index 0000000000..835a0cc440 --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -0,0 +1,488 @@ +--- +# reviewers: +# - cdrage +title: 도커 컴포즈 파일을 쿠버네티스 리소스로 변환하기 +content_type: task +weight: 200 +--- + + + +Kompose는 무엇일까? Kompose는 컴포즈(즉, Docker Compose)를 컨테이너 오케스트레이션(쿠버네티스나 오픈시프트)으로 변환하는 도구이다. + +더 자세한 내용은 Kompose 웹사이트 [http://kompose.io](http://kompose.io)에서 찾아볼 수 있다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## Kompose 설치하기 + +Kompose를 설치하기 위한 여러가지 방법들이 있다. 우리는 깃허브 최신 릴리스에서 바이너리를 다운 받는 방법을 사용할 것이다. + +{{< tabs name="install_ways" >}} +{{% tab name="깃허브 다운로드" %}} + +Kompose는 3주 주기로 깃허브에 릴리스된다. 현재 릴리스에 관한 모든 정보는 [깃허브 릴리스 페이지](https://github.com/kubernetes/kompose/releases)에서 확인할 수 있다. + +```sh +# Linux +curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose + +# macOS +curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-darwin-amd64 -o kompose + +# Windows +curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-windows-amd64.exe -o kompose.exe + +chmod +x kompose +sudo mv ./kompose /usr/local/bin/kompose +``` + +또 다른 방법으로, [tarball](https://github.com/kubernetes/kompose/releases)를 다운로드 받을 수 있다. + +{{% /tab %}} +{{% tab name="소스 빌드" %}} + +`go get`을 통해 설치를 진행하면 최신 개발 변경점을 담고 있는 마스터 브랜치를 pull 한다. + +```sh +go get -u github.com/kubernetes/kompose +``` + +{{% /tab %}} +{{% tab name="CentOS 패키지" %}} + +Kompose는 [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS 저장소이다. +만약 [EPEL](https://fedoraproject.org/wiki/EPEL) 저장소를 설치하고 활성화하지 않았다면, `sudo yum install epel-release`으로 이를 수행할 수 있다. + +시스템에 [EPEL](https://fedoraproject.org/wiki/EPEL)이 활성화되어 있다면, 다른 패키지처럼 Kompose를 설치할 수 있다. + +```bash +sudo yum -y install kompose +``` + +{{% /tab %}} +{{% tab name="페도라 패키지" %}} + +Kompose는 페도라 24, 25, 그리고 26 저장소에 있다. 다른 패키지들처럼 설치할 수 있다. + +```bash +sudo dnf -y install kompose +``` + +{{% /tab %}} +{{% tab name="Homebrew (macOS)" %}} + +macOS에서는 [Homebrew](https://brew.sh)를 통해 최신 릴리스를 설치할 수 있다. + +```bash +brew install kompose +``` + +{{% /tab %}} +{{< /tabs >}} + +## Kompose 사용하기 + +몇 단계를 수행하면, 도커 컴포즈를 쿠버네티스로 변환할 수 있다. +`docker-compose.yml` 파일만 있으면 된다. + +1. `docker-compose.yml` 파일이 존재하는 디렉토리로 이동한다. 만약 없다면, 아래 예제로 테스트한다. + + ```yaml + version: "2" + + services: + + redis-master: + image: registry.k8s.io/redis:e2e + ports: + - "6379" + + redis-slave: + image: gcr.io/google_samples/gb-redisslave:v3 + ports: + - "6379" + environment: + - GET_HOSTS_FROM=dns + + frontend: + image: gcr.io/google-samples/gb-frontend:v4 + ports: + - "80:80" + environment: + - GET_HOSTS_FROM=dns + labels: + kompose.service.type: LoadBalancer + ``` + +2. `docker-compose.yml` 파일을 `kubectl`를 통해 활용할 수 있는 파일들로 변환하기 위해서는, + `kompose convert`를 실행한 후, `kubectl apply -f `를 실행한다. + + ```bash + kompose convert + ``` + + 결과는 다음과 같다. + + ```none + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + ``` + + ```bash + kubectl apply -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml + ``` + + 결과는 다음과 같다. + + ```none + service/frontend created + service/redis-master created + service/redis-slave created + deployment.apps/frontend created + deployment.apps/redis-master created + deployment.apps/redis-slave created + ``` + + 디플로이먼트들은 쿠버네티스에서 실행된다. + +3. 애플리케이션에 접근하기. + + `minikube`를 개발 환경으로 사용하고 있다면 + + ```bash + minikube service frontend + ``` + + 이 외에는, 서비스가 사용중인 IP를 확인해보자! + + ```sh + kubectl describe svc frontend + ``` + + ```none + Name: frontend + Namespace: default + Labels: service=frontend + Selector: service=frontend + Type: LoadBalancer + IP: 10.0.0.183 + LoadBalancer Ingress: 192.0.2.89 + Port: 80 80/TCP + NodePort: 80 31144/TCP + Endpoints: 172.17.0.4:80 + Session Affinity: None + No events. + ``` + + 클라우드 환경을 사용하고 있다면, IP는 `LoadBalancer Ingress` 옆에 나열되어 있을 것이다. + + ```sh + curl http://192.0.2.89 + ``` + + + +## 사용자 가이드 + +- CLI + - [`kompose convert`](#kompose-convert) +- 문서 + - [다른 형식으로의 변환](#다른-형식으로의-변환) + - [레이블](#레이블) + - [재시작](#재시작) + - [도커 컴포즈 버전](#도커-컴포즈-버전) + +Kompose는 오픈시프트와 쿠버네티스 두 제공자를 지원한다. +`--provider` 글로벌 옵션을 통해 대상 제공자를 선택할 수 있다. 만약 제공자가 명시되지 않았다면, 쿠버네티스가 기본값으로 설정된다. + +## `kompose convert` + +Kompose는 도커 컴포즈 V1, V2, 그리고 V3 파일에 대한 쿠버네티스와 오픈시프트 오브젝트로의 변환을 지원한다. + +### 쿠버네티스 `kompose convert` 예제 + +```shell +kompose --file docker-voting.yml convert +``` + +```none +WARN Unsupported key networks - ignoring +WARN Unsupported key build - ignoring +INFO Kubernetes file "worker-svc.yaml" created +INFO Kubernetes file "db-svc.yaml" created +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "result-svc.yaml" created +INFO Kubernetes file "vote-svc.yaml" created +INFO Kubernetes file "redis-deployment.yaml" created +INFO Kubernetes file "result-deployment.yaml" created +INFO Kubernetes file "vote-deployment.yaml" created +INFO Kubernetes file "worker-deployment.yaml" created +INFO Kubernetes file "db-deployment.yaml" created +``` + +```shell +ls +``` + +```none +db-deployment.yaml docker-compose.yml docker-gitlab.yml redis-deployment.yaml result-deployment.yaml vote-deployment.yaml worker-deployment.yaml +db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml +``` + +동시에 여러 도커 컴포즈 파일들을 명시할 수도 있다 + +```shell +kompose -f docker-compose.yml -f docker-guestbook.yml convert +``` + +```none +INFO Kubernetes file "frontend-service.yaml" created +INFO Kubernetes file "mlbparks-service.yaml" created +INFO Kubernetes file "mongodb-service.yaml" created +INFO Kubernetes file "redis-master-service.yaml" created +INFO Kubernetes file "redis-slave-service.yaml" created +INFO Kubernetes file "frontend-deployment.yaml" created +INFO Kubernetes file "mlbparks-deployment.yaml" created +INFO Kubernetes file "mongodb-deployment.yaml" created +INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created +INFO Kubernetes file "redis-master-deployment.yaml" created +INFO Kubernetes file "redis-slave-deployment.yaml" created +``` + +```shell +ls +``` + +```none +mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml +frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml +frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml +redis-master-deployment.yaml +``` + +만약 여러 도커 컴포즈 파일들이 명시되면 설정들은 병합된다. 공통적인 설정들은 그 다음 파일의 내용으로 덮어씌워진다. + +### 오픈시프트 `kompose convert` 예제 + +```sh +kompose --provider openshift --file docker-voting.yml convert +``` + +```none +WARN [worker] Service cannot be created because of missing port. +INFO OpenShift file "vote-service.yaml" created +INFO OpenShift file "db-service.yaml" created +INFO OpenShift file "redis-service.yaml" created +INFO OpenShift file "result-service.yaml" created +INFO OpenShift file "vote-deploymentconfig.yaml" created +INFO OpenShift file "vote-imagestream.yaml" created +INFO OpenShift file "worker-deploymentconfig.yaml" created +INFO OpenShift file "worker-imagestream.yaml" created +INFO OpenShift file "db-deploymentconfig.yaml" created +INFO OpenShift file "db-imagestream.yaml" created +INFO OpenShift file "redis-deploymentconfig.yaml" created +INFO OpenShift file "redis-imagestream.yaml" created +INFO OpenShift file "result-deploymentconfig.yaml" created +INFO OpenShift file "result-imagestream.yaml" created +``` + +서비스 내 빌드 명령에 대한 빌드컨피그(buildconfig) 생성도 지원한다. 기본적으로, 현재 깃 브랜치에 대한 리모트 저장소를 소스 저장소로 사용한다. 그리고 현재 브랜치를 빌드를 위한 소스 브랜치로 사용한다. ``--build-repo``와 ``--build-branch`` 옵션으로 다른 소스 저장소와 브랜치를 각각 지정할 수 있다. + +```sh +kompose --provider openshift --file buildconfig/docker-compose.yml convert +``` + +```none +WARN [foo] Service cannot be created because of missing port. +INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source. +INFO OpenShift file "foo-deploymentconfig.yaml" created +INFO OpenShift file "foo-imagestream.yaml" created +INFO OpenShift file "foo-buildconfig.yaml" created +``` + +{{< note >}} +만약 ``oc create -f``로 오픈시프트 아티팩트들을 수동으로 푸쉬한다면, 이미지스트림 아티팩트를 빌드컨피그 아티팩트 이전에 푸쉬해야 한다. 해당 오픈시프트 이슈에 대한 해결방안은 https://github.com/openshift/origin/issues/4518를 참고한다. +{{< /note >}} + +## 다른 형식으로의 변환 + +`kompose`의 기본 변환은 쿠버네티스 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 [서비스](/ko/docs/concepts/services-networking/service/)를 yaml 형식으로 생성하는 것이다. 또 다른 방법으로는 `-j` 옵션으로 json을 생성할 수도 있다. 또한, [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/) 오브젝트와, [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/), [Helm](https://github.com/helm/helm) 차트를 생성할 수도 있다. + +```sh +kompose convert -j +INFO Kubernetes file "redis-svc.json" created +INFO Kubernetes file "web-svc.json" created +INFO Kubernetes file "redis-deployment.json" created +INFO Kubernetes file "web-deployment.json" created +``` + +`*-deployment.json` 파일은 디플로이먼트 오브젝트들을 담고 있다. + +```sh +kompose convert --replication-controller +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "web-svc.yaml" created +INFO Kubernetes file "redis-replicationcontroller.yaml" created +INFO Kubernetes file "web-replicationcontroller.yaml" created +``` + +`*-replicationcontroller.yaml` 파일들은 레플리케이션 컨트롤러 오브젝트들을 담고 있다. 만약 레플리카를 명시하고 싶다면, `--replicas` 플래그를 사용한다. `kompose convert --replication-controller --replicas 3`. + +```shell +kompose convert --daemon-set +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "web-svc.yaml" created +INFO Kubernetes file "redis-daemonset.yaml" created +INFO Kubernetes file "web-daemonset.yaml" created +``` + +`*-daemonset.yaml` 파일들은 데몬셋 오브젝트를 담고 있다. + +만약 [헬름](https://github.com/kubernetes/helm)을 통해 차트를 생성하고 싶다면, 아래 명령을 실행한다. + +```shell +kompose convert -c +``` + +```none +INFO Kubernetes file "web-svc.yaml" created +INFO Kubernetes file "redis-svc.yaml" created +INFO Kubernetes file "web-deployment.yaml" created +INFO Kubernetes file "redis-deployment.yaml" created +chart created in "./docker-compose/" +``` + +```shell +tree docker-compose/ +``` + +```none +docker-compose +├── Chart.yaml +├── README.md +└── templates + ├── redis-deployment.yaml + ├── redis-svc.yaml + ├── web-deployment.yaml + └── web-svc.yaml +``` + +차트 구조는 헬름 차트를 만들기 위한 골격을 제공한다. + +## 레이블 + +`kompose`는 서비스의 행동을 변환 시에 명시적으로 정의하기 위해 Kompose에 특화된 레이블들을 `docker-compose.yml` 파일에서 지원한다. + +- `kompose.service.type`는 서비스의 종류를 정의한다. + + 예를 들어 + + ```yaml + version: "2" + services: + nginx: + image: nginx + dockerfile: foobar + build: ./foobar + cap_add: + - ALL + container_name: foobar + labels: + kompose.service.type: nodeport + ``` + +- `kompose.service.expose`는 서비스가 클러스터 외부에서 접근 가능한지를 정의한다. 값이 "true"로 설정되어 있다면, 제공자는 자동으로 엔드포인트를 설정한다. 이외의 값의 경우에는, 호스트네임으로 값이 설정된다. 서비스에 여러 포드들이 정의되어 있다면, 첫번째 포트가 선택되어 노출된다. + - 쿠버네티스 제공자는, 인그레스 컨트롤러가 이미 설정되었다고 가정한 상태에서 인그레스 리소스가 생성된다. + - 오픈시프트 제공자는 라우트를 생성한다. + + 예를 들어: + + ```yaml + version: "2" + services: + web: + image: tuna/docker-counter23 + ports: + - "5000:5000" + links: + - redis + labels: + kompose.service.expose: "counter.example.com" + redis: + image: redis:3.0 + ports: + - "6379" + ``` + +현재 지원하는 옵션들은 다음과 같다. + +| Key | Value | +|----------------------|-------------------------------------| +| kompose.service.type | nodeport / clusterip / loadbalancer | +| kompose.service.expose| true / hostname | + +{{< note >}} +`kompose.service.type` 레이블은 `ports` 만을 정의해야 한다. 이 외의 경우에는 `kompose`가 실패한다. +{{< /note >}} + +## 재시작 + +만약 컨트롤러 없이 일반 파드들을 생성하고 싶다면, 도커 컴포즈에 `restart`를 명시하여 이를 정의한다. `restart` 값을 설정하였을 때 어떤 일이 일어나는지는 아래 표를 확인한다. + +| `docker-compose` `restart` | object created | Pod `restartPolicy` | +|----------------------------|-------------------|---------------------| +| `""` | controller object | `Always` | +| `always` | controller object | `Always` | +| `on-failure` | Pod | `OnFailure` | +| `no` | Pod | `Never` | + +{{< note >}} +컨트롤러 오브젝트는 `deployment`이나 `replicationcontroller`가 될 수 있다. +{{< /note >}} + +예를 들어, `pival` 서비스는 아래 파드가 될 것이다. 이 컨테이너의 계산된 값은 `pi`이다. + +```yaml +version: '2' + +services: + pival: + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restart: "on-failure" +``` + +### 디플로이먼트 설정에 관한 주의사항 + +만약 도커 컴포즈 파일에 서비스를 위한 볼륨이 명시되어 있다면, 디플로이먼트(쿠버네티스)나 디플로이먼트컨피그(오픈시프트) 전략은 "롤링 업데이트"(기본값)이 아닌 "재생성"으로 변경된다. 이것은 서비스의 여러 인스턴스들이 동시에 같은 볼륨에 접근하는 것을 막기 위함이다. + +만약 도커 컴포즈 파일의 서비스 이름에 `_`이 포함되어 있다면 (예를 들어, `web_service`와 같은), `-`으로 대체되고 서비스의 이름 또한 마찬가지로 변경될 것이다 (예를 들어, `web-service`로). 이는 쿠버네티스가 오브젝트 이름에 `_`를 허용하지 않기 때문이다. + +서비스 이름을 변경할 경우 `docker-compose` 파일의 일부가 작동하지 않을 수도 있다. + +## 도커 컴포즈 버전 + +Kompose는 다음의 도커 컴포즈 버전을 지원한다. 1, 2, 그리고 3. 버전 2.1와 3.2는 실험적인 환경이기 때문에 제한적으로 지원한다. + +호환하지 않는 도커 컴포즈 키 리스트를 포함한 3개의 버전들에 관한 모든 호환성 리스트는 [변환 문서](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md)에서 확인 할 수 있다. From b0ed70dab3e04c9250200258a8dba524079db0a2 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Tue, 13 Dec 2022 18:21:47 +0900 Subject: [PATCH 10/69] [ko] Translate concepts-services-networkings-cluster-ip-allocation.md into Korean --- .../cluster-ip-allocation.md | 148 ++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 content/ko/docs/concepts/services-networking/cluster-ip-allocation.md diff --git a/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md b/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md new file mode 100644 index 0000000000..8d8a609124 --- /dev/null +++ b/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md @@ -0,0 +1,148 @@ +--- +# reviewers: +# - sftim +# - thockin +title: 서비스 클러스터IP 할당 +content_type: concept +weight: 120 +--- + + + + +쿠버네티스에서 [서비스](/ko/docs/concepts/services-networking/service/)는 파드 집합에서 +실행되는 애플리케이션을 노출하는 추상적인 방법이다. 서비스는 +(`type: ClusterIP`인 서비스를 통해) 클러스터-범위의 가상 IP 주소를 가진다. +클라이언트는 해당 가상 IP 주소로 접속할 수 있으며, 쿠버네티스는 해당 서비스를 거치는 트래픽을 +서비스 뒷단의 파드들에게 로드 밸런싱한다. + + + +## 어떻게 서비스 클러스터IP가 할당되는가? + +쿠버네티스가 서비스에 가상 IP를 할당해야 할 때, +해당 요청분에는 두가지 방법 중 하나가 수행된다. + +_동적 할당_ +: 클러스터의 컨트롤 플레인이 자동으로 `type: ClusterIP` 서비스의 설정된 IP 범위 내에서 가용 IP 주소를 선택한다. + +_정적 할당_ +: 서비스용으로 설정된 IP 범위 내에서 사용자가 IP 주소를 선택한다. + +클러스터 전체에 걸쳐, 모든 서비스의 `ClusterIP`는 항상 고유해야 한다. +이미 할당된 특정 `ClusterIP`로 서비스를 생성하려고 하면 +에러가 발생한다. + +## 왜 서비스 클러스터 IP를 예약해야 하는가? + +때로는 클러스터의 다른 컴포넌트들이나 사용자들이 사용할 수 있도록 이미 알려진 IP 주소를 통해 +서비스를 실행하고 싶을 것이다. + +가장 좋은 방법은 클러스터의 DNS 서비스이다. +가벼운 관례로 일부 쿠버네티스 설치 관리자들은 DNS 서비스의 10번째 주소를 서비스 IP 범위로 지정한다. +클러스터의 서비스 IP 범위가 10.96.0.0/16 인 상황에서 DNS 서비스 IP를 10.96.0.10 으로 지정하고 싶다면, +아래와 같이 서비스를 생성해야 할 것이다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + k8s-app: kube-dns + kubernetes.io/cluster-service: "true" + kubernetes.io/name: CoreDNS + name: kube-dns + namespace: kube-system +spec: + clusterIP: 10.96.0.10 + ports: + - name: dns + port: 53 + protocol: UDP + targetPort: 53 + - name: dns-tcp + port: 53 + protocol: TCP + targetPort: 53 + selector: + k8s-app: kube-dns + type: ClusterIP +``` + +하지만 이전에도 설명했듯이, IP 주소 10.96.0.10는 예약된 상태가 아니다. 만약 다른 서비스들이 +그 전에 동적 할당으로 생성되었거나, 동시에 생성되었다면, 해당 서비스들이 IP를 할당받았을 수도 있다. +따라서, 충돌 에러로 인해 DNS 서비스를 생성하지 못할 것이다. + +## 어떻게 하면 서비스 클러스터IP 충돌을 피할 수 있는가? {#avoid-ClusterIP-conflict} + +쿠버네티스에 구현된 할당 전략은 +서비스에 클러스터IP 할당의 충돌 위험을 줄여준다. + +`ClusterIP` 범위는 16 이상 256 미만의 단계적인 차수를 나타내는 +`min(max(16, cidrSize / 16), 256)` 공식을 기반으로 나누어져 있다. + +동적 IP 할당은 기본값으로 위쪽 밴드를 사용한다. 위쪽 범위가 모두 소진되었다면 아래쪽 밴드를 +사용할 것이다. 이것은 사용자로 하여금 아래쪽 밴드의 정적 할당을 낮은 충돌 확률로 수행할 수 있게 +해준다. + +## 예시 {#allocation-examples} + +### 예시 1 {#allocation-example-1} + +아래 예시는 서비스 IP 주소들로 10.96.0.0/24 (CIDR 표기법) IP 주소 범위를 +사용한다. + +범위 크기: 28 - 2 = 254 +밴드 오프셋: `min(max(16, 256/16), 256)` = `min(16, 256)` = 16 +정적 밴드 시작점: 10.96.0.1 +정적 밴드 끝점: 10.96.0.16 +범위 끝점: 10.96.0.254 + +{{< mermaid >}} +pie showData + title 10.96.0.0/24 + "정적" : 16 + "동적" : 238 +{{< /mermaid >}} + +### 예시 2 {#allocation-example-2} + +아래 예시는 서비스 IP 주소들로 10.96.0.0/20 (CIDR 표기법) IP 주소 범위를 +사용한다. + +범위 크기: 212 - 2 = 4094 +밴드 오프셋: `min(max(16, 4096/16), 256)` = `min(256, 256)` = 256 +정적 밴드 시작점: 10.96.0.1 +정적 밴드 끝점: 10.96.1.0 +범위 끝점: 10.96.15.254 + +{{< mermaid >}} +pie showData + title 10.96.0.0/20 + "정적" : 256 + "동적" : 3838 +{{< /mermaid >}} + +### 예시 3 {#allocation-example-3} + +아래 예시는 서비스 IP 주소들로 10.96.0.0/16 (CIDR 표기법) IP 주소 범위를 +사용한다. + +범위 크기: 216 - 2 = 65534 +밴드 오프셋: `min(max(16, 65536/16), 256)` = `min(4096, 256)` = 256 +정적 밴드 시작점: 10.96.0.1 +정적 밴드 끝점: 10.96.1.0 +범위 끝점: 10.96.255.254 + +{{< mermaid >}} +pie showData + title 10.96.0.0/16 + "정적" : 256 + "동적" : 65278 +{{< /mermaid >}} + +## {{% heading "whatsnext" %}} + +* [클라이언트 소스 IP 보존하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해 알아보기 +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 알아보기 +* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 알아보기 From 0e256c531c1db8f6f2b76ea4ba85bddec05c2e66 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Fri, 24 Feb 2023 04:36:55 +0000 Subject: [PATCH 11/69] Simplify Korean localization for main page --- content/ko/community/_index.html | 2 +- content/ko/docs/home/supported-doc-versions.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 867916e208..b0e700ec19 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -1,5 +1,5 @@ --- -title: Community +title: 커뮤니티 layout: basic cid: community community_styles_migrated: true diff --git a/content/ko/docs/home/supported-doc-versions.md b/content/ko/docs/home/supported-doc-versions.md index 4181a64e37..fe524e0f1a 100644 --- a/content/ko/docs/home/supported-doc-versions.md +++ b/content/ko/docs/home/supported-doc-versions.md @@ -1,11 +1,11 @@ --- -title: 사용 가능한 문서의 버전 +title: 가용 문서 버전 content_type: custom layout: supported-versions card: name: about weight: 10 - title: 사용 가능한 문서 버전 + title: 가용 문서 버전 --- 이 웹사이트에서는 쿠버네티스 현재 버전 및 From 21fc9707f5c6aa0175d64a782ba86073719ab742 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Tue, 13 Dec 2022 18:11:59 +0900 Subject: [PATCH 12/69] [ko] translate task-assign-cpu-resource.md into Korean --- .../assign-cpu-resource.md | 278 ++++++++++++++++++ .../pods/resource/cpu-request-limit-2.yaml | 17 ++ .../pods/resource/cpu-request-limit.yaml | 17 ++ 3 files changed, 312 insertions(+) create mode 100644 content/ko/docs/tasks/configure-pod-container/assign-cpu-resource.md create mode 100644 content/ko/examples/pods/resource/cpu-request-limit-2.yaml create mode 100644 content/ko/examples/pods/resource/cpu-request-limit.yaml diff --git a/content/ko/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-cpu-resource.md new file mode 100644 index 0000000000..c46ecd0e60 --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -0,0 +1,278 @@ +--- +title: 컨테이너 및 파드 CPU 리소스 할당 +content_type: task +weight: 20 +--- + + + +이 페이지에서는 컨테이너의 CPU *요청량*과 CPU *상한*을 지정하는 방법을 보여준다. +컨테이너는 설정된 상한보다 더 많은 CPU는 사용할 수 없다. +제공된 시스템에 CPU 가용량이 남아있다면, 컨테이너는 요청량만큼의 CPU를 할당받는 것을 +보장받는다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +태스크 예제를 수행하기 위해서는 최소 1개의 CPU가 가용한 클러스터가 필요하다. + +이 페이지의 몇 가지 단계를 수행하기 위해서는 클러스터 내 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) +서비스 실행이 필요하다. 이미 실행 중인 metrics-server가 있다면 +다음 단계를 건너뛸 수 있다. + +{{< glossary_tooltip term_id="minikube" >}}를 사용 중이라면, +다음 명령어를 실행해 metric-server를 활성화할 수 있다. + +```shell +minikube addons enable metrics-server +``` + +metric-server(아니면 `metrics.k8s.io`와 같은 다른 제공자의 리소스 메트릭 API)가 +실행 중인지를 확인하기 위해 다음의 명령어를 실행한다. + +```shell +kubectl get apiservices +``` + +리소스 메트릭 API를 사용할 수 있다면 출력에 `metrics.k8s.io`에 +대한 참조가 포함되어 있을 것이다. + + +``` +NAME +v1beta1.metrics.k8s.io +``` + + + + + + +## 네임스페이스 생성 + +이 예제에서 생성한 자원과 클러스터 내 나머지를 분리하기 위해 +{{< glossary_tooltip term_id="namespace" >}}를 생성한다. + +```shell +kubectl create namespace cpu-example +``` + +## CPU 요청량 및 상한 지정 + +컨테이너에 CPU 요청량을 지정하기 위해서는 컨테이너의 리소스 매니페스트에 `resources:requests` +필드를 포함한다. CPU 상한을 지정하기 위해서는 `resources:limits` 필드를 포함한다. + +이 예제에서는, 하나의 컨테이너를 가진 파드를 생성한다. +컨테이너는 0.5 CPU 요청량과 1 CPU 상한을 갖는다. 아래는 파드의 구성 파일이다. + +{{< codenew file="pods/resource/cpu-request-limit.yaml" >}} + +구성 파일 내 `args` 섹션은 컨테이너가 시작될 때 인수(argument)를 제공한다. +`-cpus "2"` 인수는 컨테이너가 2 CPU 할당을 시도하도록 한다. + +파드 생성: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example +``` + +파드가 실행 중인지 확인: + +```shell +kubectl get pod cpu-demo --namespace=cpu-example +``` + +파드에 대한 자세한 정보 확인: + +```shell +kubectl get pod cpu-demo --output=yaml --namespace=cpu-example +``` + +출력은 파드 내 하나의 컨테이너에 0.5 milliCPU 요청량과 +1 CPU 상한이 있는 것을 보여준다. + +```yaml +resources: + limits: + cpu: "1" + requests: + cpu: 500m +``` + +`kubectl top`을 실행하여 파드 메트릭 가져오기: + +```shell +kubectl top pod cpu-demo --namespace=cpu-example +``` + +출력은 파드가 974 milliCPU를 사용하는 것을 보여주는데, +이는 파드의 1 CPU 상한보다는 약간 적은 수치이다. + +``` +NAME CPU(cores) MEMORY(bytes) +cpu-demo 974m +``` + +만약 `-cpu "2"`로 설정한다면, 컨테이너가 2 CPU를 사용하도록 설정한 것이 된다. 하지만 컨테이너는 1 CPU까지만을 사용하도록 허용되어 있다는 사실을 기억하자. 컨테이너는 상한보다 더 많은 CPU 리소스를 사용하려고 하기 때문에, 컨테이너의 CPU 사용은 쓰로틀(throttled) 될 것이다. + +{{< note >}} +CPU 사용이 1.0보다 낮은 것에 대한 또 다른 원인은, 노드에 충분한 CPU 리소스가 가용하지 않기 때문일 수도 있다. +"시작하기 전에"의 요구사항에서 이 예제를 위해 클러스터는 최소 1 CPU가 필요하다는 사실을 기억하자. 만약 컨테이너가 1 CPU 밖에 가지고 있지 않은 노드 위에서 실행된다면, 컨테이너는 자신에게 명시되어 있는 CPU 상한과 무관하게 1 CPU 이상으로 사용하지 못할 것이다. +{{< /note >}} + +## CPU 단위(unit) + +CPU 리소스는 _CPU_ 단위로 측정된다. 쿠버네티스에서 1 CPU는, 다음과 같다. + +- 1 AWS vCPU +- 1 GCP Core +- 1 Azure vCore +- 1 하이퍼스레드 (베어메탈 서버의 하이퍼스레딩 인텔 프로세서) + +분수 값도 가능하다. 0.5 CPU를 요청한 컨테이너는 1 CPU를 요청한 컨테이너 CPU의 절반 가량을 보장받는다. +접미사 m을 사용하여 밀리(milli)를 표현할 수도 있다. 예를 들어서 100m CPU, 100milliCPU, +그리고 0.1 CPU는 모두 같다. 1m보다 정밀한 표현은 허용하지 않는다. + +CPU는 상대적인 수량이 아닌, 절대적인 수량으로 요청된다. +즉 0.1는 싱글 코어, 듀얼 코어, 48-코어 머신에서도 같은 양을 나타낸다. + +파드 삭제: + +```shell +kubectl delete pod cpu-demo --namespace=cpu-example +``` + +## 노드보다 훨씬 높은 CPU 요청량을 지정할 경우 + +CPU 요청량과 상한은 컨테이너와 연관되어 있지만, +파드가 CPU 요청량과 상한을 갖는다고 생각하는 것이 유용하다. +특정 파드의 CPU 요청량은 해당 파드의 모든 컨테이너 CPU 요청량의 합과 같다. +마찬가지로, 특정 파드의 CPU 상한은 해당 파드의 모든 컨테이너 CPU 상한의 합과 같다. + +파드 스케줄링은 요청량에 따라 수행된다. 파드는 파드 CPU 요청량을 만족할 정도로 +노드에 충분한 CPU 리소스가 있을 때에만 노드에 스케줄링한다. + +이 예제에서는, 클러스터의 모든 노드 가용량을 초과하는 CPU 요청량을 +가진 파드를 생성했다. 아래는 하나의 컨테이너를 가진 파드에 대한 설정 파일이다. +컨테이너는 100 CPU을 요청하고 있는데, 이것은 클러스터의 모든 노드 가용량을 +초과하는 것이다. + +{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}} + +파드 생성: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example +``` + +파드 상태 확인: + +```shell +kubectl get pod cpu-demo-2 --namespace=cpu-example +``` + +출력은 파드 상태가 Pending 상태임을 보여준다. 이것은 파드는 어떤 노드에서도 실행되도록 +스케줄되지 않았고, 이후에도 Pending 상태가 지속될 것이라는 것을 의미한다. + + +``` +NAME READY STATUS RESTARTS AGE +cpu-demo-2 0/1 Pending 0 7m +``` + +이벤트를 포함한 파드 상세 정보 확인: + + +```shell +kubectl describe pod cpu-demo-2 --namespace=cpu-example +``` + +출력은 노드의 CPU 리소스가 부족하여 +파드가 스케줄링될 수 없음을 보여준다. + + +``` +Events: + Reason Message + ------ ------- + FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3). +``` + +파드 삭제: + +```shell +kubectl delete pod cpu-demo-2 --namespace=cpu-example +``` + +## CPU 상한을 지정하지 않을 경우 + +컨테이너에 CPU 상한을 지정하지 않으면 다음 상황 중 하나가 발생한다. + +- 컨테이너가 사용할 수 있는 CPU 리소스에 상한선이 없다. + 컨테이너는 실행 중인 노드에서 사용 가능한 모든 CPU 리소스를 사용해버릴 수도 있다. + +- 기본 CPU 상한이 지정된 네임스페이스에서 실행 중인 컨테이너에는 해당 기본 상한이 자동으로 + 할당된다. 클러스터 관리자들은 + [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)를 사용해 + CPU 상한의 기본 값을 지정할 수 있다. + +## CPU 상한은 지정했지만 CPU 요청량을 지정하지 않을 경우 + +만약 CPU 상한은 지정했지만 CPU 요청량을 지정하지 않았다면, 쿠버네티스는 자동으로 +상한에 맞는 CPU 요청량을 지정한다. 비슷하게, 컨테이너가 자신의 메모리 상한을 지정했지만 +메모리 요청량을 지정하지 않았다면, 쿠버네티스는 자동으로 상한에 맞는 +메모리 요청량을 지정한다. + +## CPU 요청량 및 상한 개념 도입 동기 + +클러스터에서 실행되는 컨테이너에 CPU 요청량과 상한을 구성하면 +클러스터 내 노드들의 가용 가능한 CPU 리소스를 효율적으로 사용할 수 있게 된다. +파드의 CPU 요청량을 낮게 유지하면 파드가 높은 확률로 스케줄링 될 수 있다. +CPU 상한이 CPU 요청량보다 크도록 설정한다면 다음 두 가지를 달성할 수 있다. + +- 가용한 CPU 리소스가 있는 경우 파드가 이를 버스트(burst) 하여 사용할 수 있다. +- 파드가 버스트 중 사용할 수 있는 CPU 리소스 양을 적절히 제한할 수 있다. + +## 정리 + +네임스페이스 삭제: + +```shell +kubectl delete namespace cpu-example +``` + + + +## {{% heading "whatsnext" %}} + + + +### 앱 개발자들을 위한 문서 + +- [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) + +- [파드에 대한 서비스 품질 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) + +### 클러스터 관리자들을 위한 문서 + +- [네임스페이스에 대한 기본 메모리 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) + +- [네임스페이스에 대한 기본 CPU 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) + +- [네임스페이스에 대한 메모리의 최소 및 최대 메모리 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) + +- [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) + +- [네임스페이스에 대한 메모리 및 CPU 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) + +- [네임스페이스에 대한 파드 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) + +- [API 오브젝트 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/) + + diff --git a/content/ko/examples/pods/resource/cpu-request-limit-2.yaml b/content/ko/examples/pods/resource/cpu-request-limit-2.yaml new file mode 100644 index 0000000000..f505c77fbb --- /dev/null +++ b/content/ko/examples/pods/resource/cpu-request-limit-2.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: cpu-demo-2 + namespace: cpu-example +spec: + containers: + - name: cpu-demo-ctr-2 + image: vish/stress + resources: + limits: + cpu: "100" + requests: + cpu: "100" + args: + - -cpus + - "2" diff --git a/content/ko/examples/pods/resource/cpu-request-limit.yaml b/content/ko/examples/pods/resource/cpu-request-limit.yaml new file mode 100644 index 0000000000..2cc0b2cf4f --- /dev/null +++ b/content/ko/examples/pods/resource/cpu-request-limit.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: cpu-demo + namespace: cpu-example +spec: + containers: + - name: cpu-demo-ctr + image: vish/stress + resources: + limits: + cpu: "1" + requests: + cpu: "0.5" + args: + - -cpus + - "2" From 91ae8b261c29aace7effb0c375458cb8021eda12 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 16 Dec 2022 15:02:23 +0900 Subject: [PATCH 13/69] [ko] Update outdated files in dev-1.26-ko.1 M111 --- .../feature-gates-removed.md | 679 ++++++++++++++++ .../feature-gates.md | 737 ++++-------------- 2 files changed, 815 insertions(+), 601 deletions(-) create mode 100644 content/ko/docs/reference/command-line-tools-reference/feature-gates-removed.md diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates-removed.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates-removed.md new file mode 100644 index 0000000000..7d4aa74e4f --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates-removed.md @@ -0,0 +1,679 @@ +--- +title: 제거된 기능 게이트 +weight: 15 +content_type: concept +--- + + + +이 페이지는 그간 제거된 기능 게이트의 목록을 나열한다. +이 페이지의 정보는 참고용이다. +제거된(removed) 기능 게이트는 더 이상 유효한 기능 게이트로 인식되지 않는다는 점에서 졸업(GA'ed)이나 사용 중단된(deprecated) 기능 게이트와 다르다. +반면, 승급되거나 사용 중단된 기능 게이트는 +다른 쿠버네티스 컴포넌트가 인식할 수는 있지만 클러스터에서 어떠한 동작 차이도 유발하지 않는다. + +쿠버네티스 컴포넌트가 인식할 수 있는 기능 게이트를 보려면, +[알파/베타 기능 게이트 표](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트) 또는 +[승급/사용 중단 기능 게이트 표](/ko/docs/reference/command-line-tools-reference/feature-gates/#승급-또는-사용-중단된-기능을-위한-기능-게이트)를 참고한다. + +### 제거된 기능 게이트 + +다음은 아래 테이블에 대한 설명이다. + +- "도입" 열은 해당 기능이 처음 도입되거나 릴리스 단계가 변경된 + 쿠버네티스 릴리스를 나타낸다. +- "종료" 열에 값이 있다면, 해당 기능 게이트를 사용할 수 있는 마지막 쿠버네티스 릴리스를 나타낸다. + 만약 기능 단계가 "사용 중단" 또는 "GA" 라면, + "종료" 열의 값은 해당 기능이 제거된 쿠버네티스 릴리스를 나타낸다. + +{{< table caption="제거된 기능 게이트" >}} + +| 기능 | 디폴트 | 단계 | 도입 | 종료 | +|---------|---------|-------|-------|-------| +| `Accelerators` | `false` | 알파 | 1.6 | 1.10 | +| `Accelerators` | - | 사용 중단 | 1.11 | 1.11 | +| `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 | +| `AffinityInAnnotations` | - | 사용 중단 | 1.8 | 1.8 | +| `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 | +| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | 1.9 | +| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | +| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | +| `AttachVolumeLimit` | `true` | GA | 1.17 | 1.21 | +| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 | +| `BalanceAttachedNodeVolumes` | `false` | 사용 중단 | 1.22 | 1.22 | +| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | +| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | +| `BlockVolume` | `true` | GA | 1.18 | 1.21 | +| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 | +| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 | +| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | 1.23 | +| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | +| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 | +| `CRIContainerLogRotation` | `true` | GA | 1.21 | 1.22 | +| `CSIBlockVolume` | `false` | 알파 | 1.11 | 1.13 | +| `CSIBlockVolume` | `true` | 베타 | 1.14 | 1.17 | +| `CSIBlockVolume` | `true` | GA | 1.18 | 1.21 | +| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | +| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | +| `CSIDriverRegistry` | `true` | GA | 1.18 | 1.21 | +| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationAWSComplete` | - | 사용 중단 | 1.21 | 1.21 | +| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationAzureDiskComplete` | - | 사용 중단 | 1.21 | 1.21 | +| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationAzureFileComplete` | - | 사용 중단 | 1.21 | 1.21 | +| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationGCEComplete` | - | 사용 중단 | 1.21 | 1.21 | +| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationOpenStackComplete` | - | 사용 중단 | 1.21 | 1.21 | +| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 | +| `CSIMigrationvSphereComplete` | - | 사용 중단 | 1.22 | 1.22 | +| `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 | +| `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 | +| `CSINodeInfo` | `true` | GA | 1.17 | 1.22 | +| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 | +| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 | +| `CSIPersistentVolume` | `true` | GA | 1.13 | 1.16 | +| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 | +| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 | +| `CSIServiceAccountToken` | `true` | GA | 1.22 | 1.24 | +| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 | +| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 | +| `CSIVolumeFSGroupPolicy` | `true` | GA | 1.23 | 1.25 | +| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 | +| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 | +| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | 1.25 | +| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | +| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 | +| `CronJobControllerV2` | `true` | GA | 1.22 | 1.23 | +| `CSRDuration` | `true` | 베타 | 1.22 | 1.23 | +| `CSRDuration` | `true` | GA | 1.24 | 1.25 | +| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | +| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | +| `CustomPodDNS` | `true` | GA | 1.14 | 1.16 | +| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 | +| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | 1.16 | +| `CustomResourceDefaulting` | `true` | GA | 1.17 | 1.18 | +| `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 | +| `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 | +| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | 1.18 | +| `CustomResourceSubresources` | `false` | 알파 | 1.10 | 1.10 | +| `CustomResourceSubresources` | `true` | 베타 | 1.11 | 1.15 | +| `CustomResourceSubresources` | `true` | GA | 1.16 | 1.18 | +| `CustomResourceValidation` | `false` | 알파 | 1.8 | 1.8 | +| `CustomResourceValidation` | `true` | 베타 | 1.9 | 1.15 | +| `CustomResourceValidation` | `true` | GA | 1.16 | 1.18 | +| `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | +| `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | +| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | 1.18 | +| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 | +| `DynamicAuditing` | - | 사용 중단 | 1.19 | 1.19 | +| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | +| `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - | +| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | +| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | 1.12 | +| `EnableAggregatedDiscoveryTimeout` | `true` | 사용 중단 | 1.16 | 1.17 | +| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.12 | +| `EnableEquivalenceClassCache` | - | 사용 중단 | 1.13 | 1.23 | +| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | +| `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 | +| `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 | +| `EndpointSlice` | `true` | GA | 1.21 | 1.24 | +| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 | +| `EndpointSliceNodeName` | `true` | GA | 1.21 | 1.24 | +| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 | +| `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 | +| `EndpointSliceProxying` | `true` | GA | 1.22 | 1.24 | +| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | +| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | +| `EvenPodsSpread` | `true` | GA | 1.19 | 1.21 | +| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | +| `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | 1.16 | +| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | 1.22 | +| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | +| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | 1.16 | +| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | 1.20 | +| `GenericEphemeralVolume` | `true` | 베타 | 1.21 | 1.22 | +| `GenericEphemeralVolume` | `true` | GA | 1.23 | 1.24 | +| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 | +| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 | +| `HugePageStorageMediumSize` | `true` | GA | 1.22 | 1.24 | +| `HugePages` | `false` | 알파 | 1.8 | 1.9 | +| `HugePages` | `true` | 베타| 1.10 | 1.13 | +| `HugePages` | `true` | GA | 1.14 | 1.16 | +| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 | +| `HyperVContainer` | `false` | 사용 중단 | 1.20 | 1.20 | +| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | +| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 | +| `IPv6DualStack` | `true` | GA | 1.23 | 1.24 | +| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | +| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 | +| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | 1.24 | +| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 | +| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | 1.22 | +| `IngressClassNamespacedParams` | `true` | GA | 1.23 | 1.24 | +| `Initializers` | `false` | 알파 | 1.7 | 1.13 | +| `Initializers` | - | 사용 중단 | 1.14 | 1.14 | +| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | +| `KubeletConfigFile` | - | 사용 중단 | 1.10 | 1.10 | +| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 | +| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 | +| `KubeletPluginsWatcher` | `true` | GA | 1.13 | 1.16 | +| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | +| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | +| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | 1.22 | +| `MountContainers` | `false` | 알파 | 1.9 | 1.16 | +| `MountContainers` | `false` | 사용 중단 | 1.17 | 1.17 | +| `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | +| `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | +| `MountPropagation` | `true` | GA | 1.12 | 1.14 | +| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 | +| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | 1.23 | +| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | +| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | +| `NodeDisruptionExclusion` | `true` | GA | 1.21 | 1.22 | +| `NodeLease` | `false` | 알파 | 1.12 | 1.13 | +| `NodeLease` | `true` | 베타 | 1.14 | 1.16 | +| `NodeLease` | `true` | GA | 1.17 | 1.23 | +| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | +| `PVCProtection` | - | 사용 중단 | 1.10 | 1.10 | +| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | +| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | +| `PersistentLocalVolumes` | `true` | GA | 1.14 | 1.16 | +| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 | +| `PodDisruptionBudget` | `true` | GA | 1.21 | 1.25 | +| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | +| `PodOverhead` | `true` | 베타 | 1.18 | 1.23 | +| `PodOverhead` | `true` | GA | 1.24 | 1.25 | +| `PodPriority` | `false` | 알파 | 1.8 | 1.10 | +| `PodPriority` | `true` | 베타 | 1.11 | 1.13 | +| `PodPriority` | `true` | GA | 1.14 | 1.18 | +| `PodReadinessGates` | `false` | 알파 | 1.11 | 1.11 | +| `PodReadinessGates` | `true` | 베타 | 1.12 | 1.13 | +| `PodReadinessGates` | `true` | GA | 1.14 | 1.16 | +| `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 | +| `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 | +| `PodShareProcessNamespace` | `true` | GA | 1.17 | 1.19 | +| `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | +| `RequestManagement` | - | 사용 중단 | 1.17 | 1.17 | +| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 | +| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | 1.19 | +| `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | +| `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | +| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | 1.18 | +| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 | +| `RootCAConfigMap` | `true` | 베타 | 1.20 | 1.20 | +| `RootCAConfigMap` | `true` | GA | 1.21 | 1.22 | +| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 | +| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | 1.21 | +| `RunAsGroup` | `true` | 베타 | 1.14 | 1.20 | +| `RunAsGroup` | `true` | GA | 1.21 | 1.22 | +| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | +| `RuntimeClass` | `true` | 베타 | 1.14 | 1.19 | +| `RuntimeClass` | `true` | GA | 1.20 | 1.24 | +| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 | +| `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 | +| `SCTPSupport` | `true` | GA | 1.20 | 1.22 | +| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 | +| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 | +| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | 1.18 | +| `SelectorIndex` | `false` | 알파 | 1.18 | 1.18 | +| `SelectorIndex` | `true` | 베타 | 1.19 | 1.19 | +| `SelectorIndex` | `true` | GA | 1.20 | 1.25 | +| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 | +| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 | +| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | 1.23 | +| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | +| `ServiceAppProtocol` | `true` | 베타 | 1.19 | 1.19 | +| `ServiceAppProtocol` | `true` | GA | 1.20 | 1.22 | +| `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | +| `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | +| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | 1.20 | +| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | +| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | +| `ServiceNodeExclusion` | `true` | GA | 1.21 | 1.22 | +| `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 | +| `ServiceTopology` | `false` | 사용 중단 | 1.20 | 1.22 | +| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | +| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 | +| `SetHostnameAsFQDN` | `true` | GA | 1.22 | 1,24 | +| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | +| `StartupProbe` | `true` | 베타 | 1.18 | 1.19 | +| `StartupProbe` | `true` | GA | 1.20 | 1.23 | +| `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | +| `StorageObjectInUseProtection` | `true` | GA | 1.11 | 1.24 | +| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | +| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 | +| `StreamingProxyRedirects` | `true` | 사용 중단 | 1.18 | 1.21 | +| `StreamingProxyRedirects` | `false` | 사용 중단 | 1.22 | 1.24 | +| `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | +| `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | +| `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | +| `SupportIPVSProxyMode` | `true` | GA | 1.11 | 1.20 | +| `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 | +| `SupportNodePidsLimit` | `true` | 베타 | 1.15 | 1.19 | +| `SupportNodePidsLimit` | `true` | GA | 1.20 | 1.23 | +| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | +| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 | +| `SupportPodPidsLimit` | `true` | GA | 1.20 | 1.23 | +| `Sysctls` | `true` | 베타 | 1.11 | 1.20 | +| `Sysctls` | `true` | GA | 1.21 | 1.22 | +| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | 베타 | 1.21 | 1.22 | +| `TTLAfterFinished` | `true` | GA | 1.23 | 1.24 | +| `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 | +| `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 | +| `TaintBasedEvictions` | `true` | GA | 1.18 | 1.20 | +| `TaintNodesByCondition` | `false` | 알파 | 1.8 | 1.11 | +| `TaintNodesByCondition` | `true` | 베타 | 1.12 | 1.16 | +| `TaintNodesByCondition` | `true` | GA | 1.17 | 1.18 | +| `TokenRequest` | `false` | 알파 | 1.10 | 1.11 | +| `TokenRequest` | `true` | 베타 | 1.12 | 1.19 | +| `TokenRequest` | `true` | GA | 1.20 | 1.21 | +| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 | +| `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 | +| `TokenRequestProjection` | `true` | GA | 1.20 | 1.21 | +| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | +| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 | +| `ValidateProxyRedirects` | `true` | 사용 중단 | 1.22 | 1.24 | +| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | +| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | +| `VolumePVCDataSource` | `true` | GA | 1.18 | 1.21 | +| `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 | +| `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 | +| `VolumeScheduling` | `true` | GA | 1.13 | 1.16 | +| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | +| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 | +| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | 1.22 | +| `VolumeSubpath` | `true` | GA | 1.10 | 1.24 | +| `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 | +| `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 | +| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | 1.24 | +| `WarningHeaders` | `true` | 베타 | 1.19 | 1.21 | +| `WarningHeaders` | `true` | GA | 1.22 | 1.24 | +| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 | +| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | 1.21 | +| `WindowsEndpointSliceProxying` | `true` | GA | 1.22| 1.24 | +| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 | +| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 | +| `WindowsGMSA` | `true` | GA | 1.18 | 1.20 | +| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 | +| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 | +| `WindowsRunAsUserName` | `true` | GA | 1.18 | 1.20 | + +## Descriptions for removed feature gates + +- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는 + 플러그인의 초기 형태를 제공하였으며, 사용 중단되었다. + 대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 + 확인한다. + +- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) + 설정을 활성화한다. + +- `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다. + +- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 + 대한 제한을 보고하도록 한다. + 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 + 참고한다. + +- `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 + 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 + 더 가까운 노드가 선호된다. + +- `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. + 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 + 참고한다. + +- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 + 서비스어카운트 볼륨을 마이그레이션한다. + 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 + 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. + 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 + `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. + 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. + +- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. + 로그 파일 사이즈 기본값은 10MB이며, + 컨테이너 당 최대 로그 파일 수 기본값은 5이다. + 이 값은 kubelet 환경설정으로 변경할 수 있다. + 더 자세한 내용은 + [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. + +- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. + 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을 + 참고한다. + +- `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 + 모든 로직을 활성화한다. + +- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 + 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS + 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. + 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 + EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. + +- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 + Azure-Disk 인-트리 플러그인 등록을 중지하고 + shim 및 변환 로직을 사용하여 + 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. + 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 + AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 + `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. + +- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 + 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 + Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 + 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 + 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 + 있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는 + `InTreePluginAzureFileUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. + +- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD + 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD + 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. + CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI + 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. + +- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 + Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 + 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. + 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 + Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. + +- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 + 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 + vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 + CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 + 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. + +- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. + +- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) + 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 + 마운트할 수 있다. + +- `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록 + CSI 드라이버를 활성화한다. + [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다. + +- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. + 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 + 권한 수정을 지원하는지 여부를 제어한다. + +- `CSRDuration`: 클라이언트가 쿠버네티스 CSR API를 통해 발급된 인증서의 기간을 + 요청할 수 있다. + +- `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한 + 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 + [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 + 참고한다. + +- `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}} + 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면, + 동일한 컨트롤러의 버전 1이 선택된다. + +- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. + 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 + 확인한다. + +- `CustomResourceDefaulting`: OpenAPI v3 유효성 검사 스키마에서 기본값에 대한 CRD 지원을 활성화한다. + +- `CustomResourcePublishOpenAPI`: CRD OpenAPI 사양을 게시할 수 있다. + +- `CustomResourceSubresources`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에서 `/status` 및 `/scale` 하위 리소스를 활성화한다. + +- `CustomResourceValidation`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. + +- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 + 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. + +- `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용했다. + +- `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록 + 기본 스케줄러를 확장한다. + 이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다. + +- `DynamicVolumeProvisioning`: 파드에 퍼시스턴트 볼륨의 + [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다. + +- `EnableAggregatedDiscoveryTimeout`: 수집된 검색 호출에서 5초 + 시간 초과를 활성화한다. + +- `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의 + 동등성을 캐시할 수 있게 한다. + +- `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 + 엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. + +- `EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다. + +- `EndpointSliceProxying`: 활성화되면, 리눅스에서 실행되는 + kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 + 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. + [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. + +- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. + [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 참고한다. + +- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 + 어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. + 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. + +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 + 버그를 수정한다. + +- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. + +- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 + 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 + 등에서 제공할 수 있음). + [임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/)을 참고한다. + +- `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 + 여러 크기를 지원한다. + +- `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 + 할당 및 사용을 활성화한다. + +- `HyperVContainer`: 윈도우 컨테이너를 위한 + [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) + 기능을 활성화한다. + +- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) + 기능을 활성화한다. + +- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 + 변경할 수 없는(immutable) 것으로 표시할 수 있다. + +- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 + `IngressClass` 리소스를 참조할 수 있도록 허용한다. + 이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다. + +- `Initializers`: Initializers 어드미션 플러그인을 사용하여, + 오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다. + +- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 + kubelet 구성을 로드할 수 있다. + 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 + 참고한다. + +- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 + 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. + +- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 + `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 + `node-role.kubernetes.io/master` 레이블을 무시한다. + +- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. + +- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. + 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. + +- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) + {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. + (네임스페이스의 이름도 변경 불가) + +- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` + 사용을 활성화한다. + +- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. + +- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 + 삭제되지 않도록 한다. + +- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. + `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. + +- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. + +- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) + 기능을 활성화한다. + +- `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 + 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. + +- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 + `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 + 참고한다. + +- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 + 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 + [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. + +- `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을 + 관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다. + +- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 + 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 + 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 + 노드 사이의 관계를 끊는 것이다. + +- `ResourceQuotaScopeSelectors`: 리소스 쿼터 범위 셀렉터를 활성화한다. + +- `RootCAConfigMap`: 모든 네임스페이스에 `kube-root-ca.crt`라는 + {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 게시하도록 + `kube-controller-manager` 를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 + 사용되는 CA 번들이 포함되어 있다. 자세한 내용은 + [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 + 참조한다. + +- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. + 자세한 내용은 + [kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. + +- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다. + +- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) + 기능을 활성화한다. + +- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 + _SCTP_ `protocol` 값을 활성화한다. + +- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 + 스케줄링할 수 있다. + +- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여 + 목록 작업을 가속화할 수 있다. + +- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 + JWKS URL)를 활성화한다. 자세한 내용은 + [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 + 참고한다. + +- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다. + +- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. + +- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. + "`node.kubernetes.io/exclude-from-external-load-balancers`"로 레이블이 지정된 경우 노드를 제외할 수 있다. + +- `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. + 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. + +- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 + 설정하는 기능을 활성화한다. + [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다. + +- `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) + 프로브를 활성화한다. + +- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 + 사용 중인 경우 삭제를 연기한다. + +- `StreamingProxyRedirects`: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을 + 가로채서 따르도록 API 서버에 지시한다. + 스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다. + +- `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. + 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. + +- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. + `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` + 파라미터를 지정하여 지정된 수의 프로세스 ID가 + 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. + +- `SupportPodPidsLimit`: 파드의 PID 제한에 대한 지원을 활성화한다. + +- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. + 자세한 내용은 [sysctl](/ko/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. + +- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 + 실행이 끝난 후 리소스를 정리하도록 허용한다. + +- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 + 노드에서 파드를 축출할 수 있다. + 자세한 내용은 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 참고한다. + +- `TaintNodesByCondition`: [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)을 + 기반으로 자동 테인트 노드를 활성화한다. + +- `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다. + +- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해 + 서비스 어카운트 토큰을 파드에 주입할 수 있다. + +- `ValidateProxyRedirects`: 이 플래그는 API 서버가 동일한 호스트로만 리디렉션되는가를 확인해야 하는지 여부를 제어한다. + `StreamingProxyRedirects` 플래그가 활성화된 경우에만 사용된다. + +- `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다. + +- `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고 + 퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한 + `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때 + [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다. + +- `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다. + +- `VolumeSubpath`: 컨테이너에 볼륨의 하위 경로(subpath)를 마운트할 수 있다. + +- `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해 + `subPathExpr` 필드를 활성화한다. + +- `WarningHeaders`: API 응답에서 경고 헤더를 보낼 수 있다. + +- `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는 + 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 + 확장성과 성능을 향상시킨다. + [엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. + +- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다. + +- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 + 애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은 + [RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을 참고한다. + 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 a9eb842e5a..a9e3146476 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 @@ -21,7 +21,6 @@ card: 각 쿠버네티스 컴포넌트에서 `--feature-gates` 커맨드 라인 플래그를 사용하여 이러한 기능을 켜거나 끌 수 있다. - 각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을 활성화 또는 비활성화할 수 있다. 모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다. @@ -46,6 +45,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - [승급/사용 중단 기능 게이트 테이블](#승급-또는-사용-중단된-기능을-위한-기능-게이트)에는 사용 중단된 기능과 철회(withdrawn) 기능의 목록도 있다. +{{< note >}} +제거된 옛 기능 게이트의 레퍼런스를 보려면, +[제거된 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates-removed/) 페이지를 참고한다. +{{< /note >}} + ### 알파 또는 베타 기능을 위한 기능 게이트 {{< table caption="알파 또는 베타 단계에 있는 기능을 위한 기능 게이트" >}} @@ -58,58 +62,48 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `APIPriorityAndFairness` | `true` | 베타 | 1.20 | | | `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 | | `APIResponseCompression` | `true` | 베타 | 1.16 | | -| `APIServerIdentity` | `false` | 알파 | 1.20 | | +| `APISelfSubjectAttributesReview` | `false` | 알파 | 1.26 | | +| `APIServerIdentity` | `false` | 알파 | 1.20 | 1.25 | +| `APIServerIdentity` | `true` | 베타 | 1.26 | | | `APIServerTracing` | `false` | 알파 | 1.22 | | | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | | | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | 1.23 | | `AnyVolumeDataSource` | `true` | 베타 | 1.24 | | | `AppArmor` | `true` | 베타 | 1.4 | | -| `ContainerCheckpoint` | `false` | 알파 | 1.25 | | -| `CPUManager` | `false` | 알파 | 1.8 | 1.9 | -| `CPUManager` | `true` | 베타 | 1.10 | | | `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | | | `CPUManagerPolicyBetaOptions` | `true` | 베타 | 1.23 | | | `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | 1.22 | | `CPUManagerPolicyOptions` | `true` | 베타 | 1.23 | | -| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.20 | -| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | 1.23 | -| `CSIMigrationAzureFile` | `true` | 베타 | 1.24 | | | `CSIMigrationPortworx` | `false` | 알파 | 1.23 | 1.24 | | `CSIMigrationPortworx` | `false` | 베타 | 1.25 | | | `CSIMigrationRBD` | `false` | 알파 | 1.23 | | -| `CSIMigrationvSphere` | `false` | 알팝 | 1.18 | 1.18 | -| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | 1.24 | -| `CSIMigrationvSphere` | `true` | 베타 | 1.25 | | | `CSINodeExpandSecret` | `false` | 알파 | 1.25 | | | `CSIVolumeHealth` | `false` | 알파 | 1.21 | | +| `CrossNamespaceVolumeDataSource` | `false` | 알파| 1.26 | | +| `ContainerCheckpoint` | `false` | 알파 | 1.25 | | | `ContextualLogging` | `false` | 알파 | 1.24 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | | `CustomResourceValidationExpressions` | `false` | 알파 | 1.23 | 1.24 | | `CustomResourceValidationExpressions` | `true` | 베타 | 1.25 | | -| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 | -| `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | | -| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | -| `DevicePlugins` | `true` | 베타 | 1.10 | | -| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 | -| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | | | `DisableCloudProviders` | `false` | 알파 | 1.22 | | | `DisableKubeletCloudCredentialProviders` | `false` | 알파 | 1.23 | | | `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 | | `DownwardAPIHugePages` | `false` | 베타 | 1.21 | 1.21 | | `DownwardAPIHugePages` | `true` | 베타 | 1.22 | | +| `DynamicResourceAllocation` | `false` | 알파 | 1.26 | | | `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 | | `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | | | `ExpandedDNSConfig` | `false` | 알파 | 1.22 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | +| `GRPCContainerProbe` | `false` | 알파 | 1.23 | 1.23 | +| `GRPCContainerProbe` | `true` | 베타 | 1.24 | | | `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 | | `GracefulNodeShutdown` | `true` | 베타 | 1.21 | | | `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | 1.23 | | `GracefulNodeShutdownBasedOnPodPriority` | `true` | 베타 | 1.24 | | -| `GRPCContainerProbe` | `false` | 알파 | 1.23 | 1.23 | -| `GRPCContainerProbe` | `true` | 베타 | 1.24 | | -| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | | | `HPAContainerMetrics` | `false` | 알파 | 1.20 | | | `HPAScaleToZero` | `false` | 알파 | 1.16 | | +| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | | | `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | | | `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | | | `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | | @@ -118,21 +112,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `InTreePluginPortworxUnregister` | `false` | 알파 | 1.23 | | | `InTreePluginRBDUnregister` | `false` | 알파 | 1.23 | | | `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | | +| `IPTablesOwnershipCleanup` | `false` | 알파 | 1.25 | | | `JobMutableNodeSchedulingDirectives` | `true` | 베타 | 1.23 | | +| `JobPodFailurePolicy` | `false` | 알파 | 1.25 | 1.25 | +| `JobPodFailurePolicy` | `true` | 베타 | 1.26 | | | `JobReadyPods` | `false` | 알파 | 1.23 | 1.23 | | `JobReadyPods` | `true` | 베타 | 1.24 | | | `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | 1.22 | -| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | 1.23 | -| `JobTrackingWithFinalizers` | `false` | 베타 | 1.24 | | -| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | 1.23 | -| `KubeletCredentialProviders` | `true` | 베타 | 1.24 | | +| `JobTrackingWithFinalizers` | `false` | 베타 | 1.23 | 1.24 | +| `JobTrackingWithFinalizers` | `true` | 베타 | 1.25 | | +| `KMSv2` | `false` | 알파 | 1.25 | | | `KubeletInUserNamespace` | `false` | 알파 | 1.22 | | | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | 1.22 | | `KubeletPodResourcesGetAllocatable` | `true` | 베타 | 1.23 | | | `KubeletTracing` | `false` | 알파 | 1.25 | | -| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | +| `LegacyServiceAccountTokenTracking` | `false` | 알파 | 1.26 | | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | 1.24 | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `true` | 베타 | 1.25 | | | `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 | | `LogarithmicScaleDown` | `true` | 베타 | 1.22 | | | `MatchLabelKeysInPodTopologySpread` | `false` | 알파 | 1.25 | | @@ -141,46 +139,51 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `MemoryManager` | `true` | 베타 | 1.22 | | | `MemoryQoS` | `false` | 알파 | 1.22 | | | `MinDomainsInPodTopologySpread` | `false` | 알파 | 1.24 | 1.24 | -| `MinDomainsInPodTopologySpread` | `true` | 베타 | 1.25 | | +| `MinDomainsInPodTopologySpread` | `false` | 베타 | 1.25 | | | `MixedProtocolLBService` | `false` | 알파 | 1.20 | 1.23 | | `MixedProtocolLBService` | `true` | 베타 | 1.24 | | +| `MultiCIDRRangeAllocator` | `false` | 알파 | 1.25 | | | `NetworkPolicyStatus` | `false` | 알파 | 1.24 | | | `NodeInclusionPolicyInPodTopologySpread` | `false` | 알파 | 1.25 | | +| `NodeOutOfServiceVolumeDetach` | `false` | 알파 | 1.24 | 1.25 | +| `NodeOutOfServiceVolumeDetach` | `true` | 베타 | 1.26 | | | `NodeSwap` | `false` | 알파 | 1.22 | | -| `NodeOutOfServiceVolumeDetach` | `false` | 알파 | 1.24 | | | `OpenAPIEnums` | `false` | 알파 | 1.23 | 1.23 | | `OpenAPIEnums` | `true` | 베타 | 1.24 | | | `OpenAPIV3` | `false` | 알파 | 1.23 | 1.23 | | `OpenAPIV3` | `true` | 베타 | 1.24 | | +| `PDBUnhealthyPodEvictionPolicy` | `false` | 알파 | 1.26 | | | `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | | | `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 | | `PodDeletionCost` | `true` | 베타 | 1.22 | | +| `PodDisruptionConditions` | `false` | 알파 | 1.25 | 1.25 | +| `PodDisruptionConditions` | `true` | 베타 | 1.26 | | | `PodHasNetworkCondition` | `false` | 알파 | 1.25 | | -| `PodSecurity` | `false` | 알파 | 1.22 | 1.22 | -| `PodSecurity` | `true` | 베타 | 1.23 | | +| `PodSchedulingReadiness` | `false` | 알파 | 1.26 | | | `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 | | `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | 1.24 | | `ProbeTerminationGracePeriod` | `true` | 베타 | 1.25 | | | `ProcMountType` | `false` | 알파 | 1.12 | | -| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | | +| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | 1.25 | +| `ProxyTerminatingEndpoints` | `true` | 베타 | 1.26 | | | `QOSReserved` | `false` | 알파 | 1.11 | | | `ReadWriteOncePod` | `false` | 알파 | 1.22 | | | `RecoverVolumeExpansionFailure` | `false` | 알파 | 1.23 | | | `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 | | `RemainingItemCount` | `true` | 베타 | 1.16 | | +| `RetroactiveDefaultStorageClass` | `false` | 알파 | 1.25 | 1.25 | +| `RetroactiveDefaultStorageClass` | `true` | 베타 | 1.26 | | | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | +| `SELinuxMountReadWriteOncePod` | `false` | 알파 | 1.25 | | | `SeccompDefault` | `false` | 알파 | 1.22 | 1.24 | | `SeccompDefault` | `true` | 베타 | 1.25 | | | `ServerSideFieldValidation` | `false` | 알파 | 1.23 | 1.24 | | `ServerSideFieldValidation` | `true` | 베타 | 1.25 | | -| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 | -| `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | | -| `ServiceIPStaticSubrange` | `false` | 알파 | 1.24 | 1.24 | -| `ServiceIPStaticSubrange` | `true` | 베타 | 1.25 | | | `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 | | `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | | | `StatefulSetAutoDeletePVC` | `false` | 알파 | 1.22 | | +| `StatefulSetStartOrdinal` | `false` | 알파 | 1.26 | | | `StorageVersionAPI` | `false` | 알파 | 1.20 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | @@ -189,12 +192,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `TopologyAwareHints` | `true` | 베타 | 1.24 | | | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 | | `TopologyManager` | `true` | 베타 | 1.18 | | +| `TopologyManagerPolicyAlphaOptions` | `false` | 알파 | 1.26 | | +| `TopologyManagerPolicyBetaOptions` | `false` | 베타 | 1.26 | | +| `TopologyManagerPolicyOptions` | `false` | 알파 | 1.26 | | +| `UserNamespacesStatelessPodsSupport` | `false` | 알파 | 1.25 | | +| `ValidatingAdmissionPolicy` | `false` | 알파 | 1.26 | | | `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - | | `WinDSR` | `false` | 알파 | 1.14 | | | `WinOverlay` | `false` | 알파 | 1.14 | 1.19 | | `WinOverlay` | `true` | 베타 | 1.20 | | -| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | 1.22 | -| `WindowsHostProcessContainers` | `true` | 베타 | 1.23 | | +| `WindowsHostNetwork` | `false` | 알파 | 1.26| | {{< /table >}} ### 승급 또는 사용 중단된 기능을 위한 기능 게이트 @@ -203,41 +210,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | 기능 | 디폴트 | 단계 | 도입 | 종료 | |---------|---------|-------|-------|-------| -| `Accelerators` | `false` | 알파 | 1.6 | 1.10 | -| `Accelerators` | - | 사용 중단 | 1.11 | - | | `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 | | `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 | | `AdvancedAuditing` | `true` | GA | 1.12 | - | -| `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 | -| `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 | - | -| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 | -| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 | -| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | - | -| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 | -| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | 1.23 | -| `ControllerManagerLeaderMigration` | `true` | GA | 1.24 | - | -| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | -| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 | -| `CRIContainerLogRotation` | `true` | GA | 1.21 | - | -| `CSIBlockVolume` | `false` | 알파 | 1.11 | 1.13 | -| `CSIBlockVolume` | `true` | 베타 | 1.14 | 1.17 | -| `CSIBlockVolume` | `true` | GA | 1.18 | - | -| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | -| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | -| `CSIDriverRegistry` | `true` | GA | 1.18 | - | +| `CPUManager` | `false` | 알파 | 1.8 | 1.9 | +| `CPUManager` | `true` | 베타 | 1.10 | 1.25 | +| `CPUManager` | `true` | GA | 1.26 | - | | `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | | `CSIInlineVolume` | `true` | 베타 | 1.16 | 1.24 | | `CSIInlineVolume` | `true` | GA | 1.25 | - | @@ -248,108 +226,61 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 | | `CSIMigrationAWS` | `true` | 베타 | 1.23 | 1.24 | | `CSIMigrationAWS` | `true` | GA | 1.25 | - | -| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAWSComplete` | - | 사용 중단 | 1.21 | - | | `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | | `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 | | `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | 1.23 | | `CSIMigrationAzureDisk` | `true` | GA | 1.24 | | -| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAzureDiskComplete` | - | 사용 중단 | 1.21 | - | -| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAzureFileComplete` | - | 사용 중단 | 1.21 | - | +| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.20 | +| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | 1.23 | +| `CSIMigrationAzureFile` | `true` | 베타 | 1.24 | 1.25 | +| `CSIMigrationAzureFile` | `true` | GA | 1.26 | | | `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigrationGCE` | `false` | 베타 | 1.17 | 1.22 | | `CSIMigrationGCE` | `true` | 베타 | 1.23 | 1.24 | | `CSIMigrationGCE` | `true` | GA | 1.25 | - | -| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationGCEComplete` | - | 사용 중단 | 1.21 | - | +| `CSIMigrationvSphere` | `false` | 알파 | 1.18 | 1.18 | +| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | 1.24 | +| `CSIMigrationvSphere` | `true` | 베타 | 1.25 | 1.25 | +| `CSIMigrationvSphere` | `true` | GA | 1.26 | - | | `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 | | `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | 1.23 | | `CSIMigrationOpenStack` | `true` | GA | 1.24 | | -| `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 | - | -| `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 | - | | `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 | | `CSIStorageCapacity` | `true` | 베타 | 1.21 | 1.23 | | `CSIStorageCapacity` | `true` | GA | 1.24 | - | -| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 | -| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 | -| `CSIVolumeFSGroupPolicy` | `true` | GA | 1.23 | | -| `CSRDuration` | `true` | 베타 | 1.22 | 1.23 | -| `CSRDuration` | `true` | GA | 1.24 | - | -| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | -| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 | -| `CronJobControllerV2` | `true` | GA | 1.22 | - | +| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 | +| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | 1.23 | +| `ControllerManagerLeaderMigration` | `true` | GA | 1.24 | - | | `CronJobTimeZone` | `false` | 알파 | 1.24 | 1.24 | | `CronJobTimeZone` | `true` | 베타 | 1.25 | | -| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | -| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | -| `CustomPodDNS` | `true` | GA | 1.14 | - | -| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 | -| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | 1.16 | -| `CustomResourceDefaulting` | `true` | GA | 1.17 | - | -| `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 | -| `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 | -| `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - | -| `CustomResourceSubresources` | `false` | 알파 | 1.10 | 1.10 | -| `CustomResourceSubresources` | `true` | 베타 | 1.11 | 1.15 | -| `CustomResourceSubresources` | `true` | GA | 1.16 | - | -| `CustomResourceValidation` | `false` | 알파 | 1.8 | 1.8 | -| `CustomResourceValidation` | `true` | 베타 | 1.9 | 1.15 | -| `CustomResourceValidation` | `true` | GA | 1.16 | - | -| `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | -| `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | -| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | | `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 | | `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | 1.24 | | `DaemonSetUpdateSurge` | `true` | GA | 1.25 | - | | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 | | `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | 1.23 | | `DefaultPodTopologySpread` | `true` | GA | 1.24 | - | +| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 | +| `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | 1.25 | +| `DelegateFSGroupToCSIDriver` | `true` | GA | 1.26 |-| +| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 | +| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | 1.24 | +| `DisableAcceleratorUsageMetrics` | `true` | GA | 1.25 |- | +| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | +| `DevicePlugins` | `true` | 베타 | 1.10 | 1.25 | +| `DevicePlugins` | `true` | GA | 1.26 | - | | `DryRun` | `false` | 알파 | 1.12 | 1.12 | | `DryRun` | `true` | 베타 | 1.13 | 1.18 | | `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 | - | -| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | -| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - | | `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 | | `EfficientWatchResumption` | `true` | 베타 | 1.21 | 1.23 | | `EfficientWatchResumption` | `true` | GA | 1.24 | - | -| `EnableAggregatedDiscoveryTimeout` | `true` | 사용 중단 | 1.16 | - | -| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | -| `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - | -| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | -| `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 | -| `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 | -| `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 | - | | `EphemeralContainers` | `false` | 알파 | 1.16 | 1.22 | | `EphemeralContainers` | `true` | 베타 | 1.23 | 1.24 | | `EphemeralContainers` | `true` | GA | 1.25 | - | -| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | -| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | -| `EvenPodsSpread` | `true` | GA | 1.19 | - | +| `EventedPLEG` | `false` | 알파 | 1.26 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | | `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 | | `ExpandCSIVolumes` | `true` | 베타 | 1.16 | 1.23 | @@ -360,225 +291,69 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | 1.23 | | `ExpandPersistentVolumes` | `true` | GA | 1.24 |- | -| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | -| `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - | -| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | -| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | -| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | -| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | 1.20 | -| `GenericEphemeralVolume` | `true` | 베타 | 1.21 | 1.22 | -| `GenericEphemeralVolume` | `true` | GA | 1.23 | - | -| `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 | - | -| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 | -| `HyperVContainer` | `false` | 사용 중단 | 1.20 | - | | `IdentifyPodOS` | `false` | 알파 | 1.23 | 1.23 | | `IdentifyPodOS` | `true` | 베타 | 1.24 | 1.24 | | `IdentifyPodOS` | `true` | GA | 1.25 | - | -| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | -| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 | -| `IPv6DualStack` | `true` | GA | 1.23 | - | -| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | -| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 | -| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | | | `IndexedJob` | `false` | 알파 | 1.21 | 1.21 | | `IndexedJob` | `true` | 베타 | 1.22 | 1.23 | | `IndexedJob` | `true` | GA | 1.24 | - | -| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 | -| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | 1.22 | -| `IngressClassNamespacedParams` | `true` | GA | 1.23 | - | -| `Initializers` | `false` | 알파 | 1.7 | 1.13 | -| `Initializers` | - | 사용 중단 | 1.14 | - | -| `JobPodFailurePolicy` | `false` | 알파 | 1.25 | - | -| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | -| `KubeletConfigFile` | - | 사용 중단 | 1.10 | - | -| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 | -| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 | -| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | -| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | -| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | -| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | -| `LegacyServiceAccountTokenNoAutoGeneration` | `true` | 베타 | 1.24 | | +| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | 1.22 | +| `JobTrackingWithFinalizers` | `false` | 베타 | 1.23 | 1.24 | +| `JobTrackingWithFinalizers` | `true` | 베타 | 1.25 | 1.25 | +| `JobTrackingWithFinalizers` | `true` | GA | 1.26 | - | +| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | 1.23 | +| `KubeletCredentialProviders` | `true` | 베타 | 1.24 | 1.25 | +| `KubeletCredentialProviders` | `true` | GA | 1.26 | - | +| `LegacyServiceAccountTokenNoAutoGeneration` | `true` | 베타 | 1.24 | 1.25 | +| `LegacyServiceAccountTokenNoAutoGeneration` | `true` | GA | 1.26 | - | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | 1.24 | | `LocalStorageCapacityIsolation` | `true` | GA | 1.25 | - | -| `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 | - | -| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 | -| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - | | `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 | | `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | 1.24 | | `NetworkPolicyEndPort` | `true` | GA | 1.25 | - | -| `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 | - | | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | 베타 | 1.19 | 1.23 | | `NonPreemptingPriority` | `true` | GA | 1.24 | - | -| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | -| `PVCProtection` | - | 사용 중단 | 1.10 | - | -| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | -| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | -| `PersistentLocalVolumes` | `true` | GA | 1.14 | - | | `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 | | `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | 1.23 | | `PodAffinityNamespaceSelector` | `true` | GA | 1.24 | - | -| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | -| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 | -| `PodDisruptionBudget` | `true` | GA | 1.21 | - | -| `PodDisruptionConditions` | `false` | 알파 | 1.25 | - | -| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | -| `PodOverhead` | `true` | 베타 | 1.18 | 1.23 | -| `PodOverhead` | `true` | GA | 1.24 | - | -| `PodPriority` | `false` | 알파 | 1.8 | 1.10 | -| `PodPriority` | `true` | 베타 | 1.11 | 1.13 | -| `PodPriority` | `true` | GA | 1.14 | - | -| `PodReadinessGates` | `false` | 알파 | 1.11 | 1.11 | -| `PodReadinessGates` | `true` | 베타 | 1.12 | 1.13 | -| `PodReadinessGates` | `true` | GA | 1.14 | - | -| `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 | -| `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 | -| `PodShareProcessNamespace` | `true` | GA | 1.17 | - | +| `PodSecurity` | `false` | 알파 | 1.22 | 1.22 | +| `PodSecurity` | `true` | 베타 | 1.23 | 1.24 | +| `PodSecurity` | `true` | GA | 1.25 | | | `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 | | `PreferNominatedNode` | `true` | 베타 | 1.22 | 1.23 | | `PreferNominatedNode` | `true` | GA | 1.24 | - | | `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 | | `RemoveSelfLink` | `true` | 베타 | 1.20 | 1.23 | | `RemoveSelfLink` | `true` | GA | 1.24 | - | -| `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | -| `RequestManagement` | - | 사용 중단 | 1.17 | - | -| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 | -| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | - | -| `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | -| `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | -| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | -| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 | -| `RootCAConfigMap` | `true` | 베타 | 1.20 | 1.20 | -| `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 | - | -| `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 | - | -| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | -| `ServiceAppProtocol` | `true` | 베타 | 1.19 | 1.19 | -| `ServiceAppProtocol` | `true` | GA | 1.20 | - | +| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 | +| `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | 1.25 | +| `ServiceInternalTrafficPolicy` | `true` | GA | 1.26 | - | +| `ServiceIPStaticSubrange` | `false` | 알파 | 1.24 | 1.24 | +| `ServiceIPStaticSubrange` | `true` | 베타 | 1.25 | 1.25 | +| `ServiceIPStaticSubrange` | `true` | GA | 1.26 | - | | `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 | | `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | 1.23 | | `ServiceLBNodePortControl` | `true` | GA | 1.24 | - | | `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 | | `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | 1.23 | | `ServiceLoadBalancerClass` | `true` | GA | 1.24 | - | -| `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 | - | | `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | 1.22 | | `StatefulSetMinReadySeconds` | `true` | 베타 | 1.23 | 1.24 | | `StatefulSetMinReadySeconds` | `true` | GA | 1.25 | - | -| `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | -| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | -| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | -| `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 | -| `SupportIPVSProxyMode` | `true` | GA | 1.11 | - | -| `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 | -| `SupportNodePidsLimit` | `true` | 베타 | 1.15 | 1.19 | -| `SupportNodePidsLimit` | `true` | GA | 1.20 | - | -| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | -| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 | -| `SupportPodPidsLimit` | `true` | GA | 1.20 | - | | `SuspendJob` | `false` | 알파 | 1.21 | 1.21 | | `SuspendJob` | `true` | 베타 | 1.22 | 1.23 | | `SuspendJob` | `true` | GA | 1.24 | - | -| `Sysctls` | `true` | 베타 | 1.11 | 1.20 | -| `Sysctls` | `true` | GA | 1.21 | - | -| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | -| `TTLAfterFinished` | `true` | 베타 | 1.21 | 1.22 | -| `TTLAfterFinished` | `true` | GA | 1.23 | - | -| `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 | -| `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 | -| `TaintBasedEvictions` | `true` | GA | 1.18 | - | -| `TaintNodesByCondition` | `false` | 알파 | 1.8 | 1.11 | -| `TaintNodesByCondition` | `true` | 베타 | 1.12 | 1.16 | -| `TaintNodesByCondition` | `true` | GA | 1.17 | - | -| `TokenRequest` | `false` | 알파 | 1.10 | 1.11 | -| `TokenRequest` | `true` | 베타 | 1.12 | 1.19 | -| `TokenRequest` | `true` | GA | 1.20 | - | -| `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 | - | -| `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 | -| `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 | -| `VolumeScheduling` | `true` | GA | 1.13 | - | -| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | -| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 | -| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - | -| `VolumeSubpath` | `true` | GA | 1.10 | - | -| `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 | - | -| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 | -| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 | -| `WindowsRunAsUserName` | `true` | GA | 1.18 | - | +| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | 1.22 | +| `WindowsHostProcessContainers` | `true` | 베타 | 1.23 | 1.25 | +| `WindowsHostProcessContainers` | `true` | GA | 1.26 | - | {{< /table >}} ## 기능 사용 @@ -632,37 +407,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다. - `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다. 자세한 내용은 [쿠버네티스 시스템 컴포넌트에 대한 추적](/ko/docs/concepts/cluster-administration/system-traces/)페이지를 살펴본다. -- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는 - 플러그인의 초기 형태를 제공하였으며, 사용 중단되었다. - 대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 +- `APISelfSubjectAttributesReview`: 사용자로 하여금 요청을 하는 주체(subject)의 + 인증 정보를 볼 수 있도록 하는 `SelfSubjectReview` API를 활성화한다. + 더 자세한 정보는 [클라이언트로서의 인증 정보 API 접근](/docs/reference/access-authn-authz/authentication/#self-subject-review)을 확인한다. - `AdvancedAuditing`: [고급 감사](/ko/docs/tasks/debug/debug-cluster/audit/#advanced-audit) 기능을 활성화한다. -- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) - 설정을 활성화한다. -- `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다. - `AllowInsecureBackendProxy`: 사용자가 파드 로그 요청에서 kubelet의 TLS 확인을 건너뛸 수 있도록 한다. - `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의 `DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다. - `AppArmor`: 리눅스 노드에서 실행되는 파드에 대한 AppArmor 필수 접근 제어의 사용을 활성화한다. 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다. -- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 - 대한 제한을 보고하도록 한다. - 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 - 참고한다. -- `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 - 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 - 더 가까운 노드가 선호된다. -- `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. - 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 - 참고한다. -- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 - 서비스어카운트 볼륨을 마이그레이션한다. - 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. - 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 - `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. - 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ContainerCheckpoint`: kubelet의 `체크포인트` API를 활성화한다. 자세한 내용은 [kubelet 체크포인트 API](/docs/reference/node/kubelet-checkpoint-api/)를 확인한다. - `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가 @@ -682,17 +437,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다. 이 기능 게이트는 안정(stable) 상태로 승급되지 않을 것이다. - `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다. -- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. - 로그 파일 사이즈 기본값은 10MB이며, - 컨테이너 당 최대 로그 파일 수 기본값은 5이다. - 이 값은 kubelet 환경설정으로 변경할 수 있다. - 더 자세한 내용은 - [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. -- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. - 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을 - 참고한다. -- `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 - 모든 로직을 활성화한다. +- `CrossNamespaceVolumeDataSource`: 네임스페이스간 볼륨 데이터 소스 사용 기능을 + 활성화하며, 퍼시스턴트볼륨클레임의 `dataSourceRef` 필드에 소스 네임스페이스를 + 기재할 수 있게 된다. - `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다. - `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다. @@ -702,13 +449,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다. 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. -- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 - 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS - 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. - 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 - EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다. - 이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. - `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 @@ -716,14 +456,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. -- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 - Azure-Disk 인-트리 플러그인 등록을 중지하고 - shim 및 변환 로직을 사용하여 - 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. - 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 - AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. - 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 - `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 @@ -731,14 +463,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. -- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 - 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 - Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 - 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 - 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 - 있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는 - `InTreePluginAzureFileUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 @@ -746,13 +470,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. -- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD - 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD - 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. - CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI - 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. - 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 @@ -760,13 +477,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. -- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 - Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 - 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. - 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 - Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. - 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. - `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. 클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, @@ -780,63 +490,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 프로비전 동작에 대해서는 폴백을 지원하지 않는데, 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. -- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 - 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 - vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 - CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 - 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. - 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. - `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다. -- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSINodeExpandSecret`: CSI 드라이버가 `NodeExpandVolume` 작업 수행 중에 사용할 수 있도록 시크릿 인증 데이터를 드라이버에 전송 가능하게 한다. -- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) - 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 - 마운트할 수 있다. -- `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록 - CSI 드라이버를 활성화한다. - [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다. - `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. [스토리지 용량](/ko/docs/concepts/storage/storage-capacity/)을 참고한다. 자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다. -- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. - 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 - 권한 수정을 지원하는지 여부를 제어한다. - `CSIVolumeHealth`: 노드에서의 CSI 볼륨 상태 모니터링 기능을 활성화한다. -- `CSRDuration`: 클라이언트가 쿠버네티스 CSR API를 통해 발급된 인증서의 기간을 - 요청할 수 있다. -- `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한 - 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 - [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 - 참고한다. - `ContextualLogging`: 이 기능을 활성화하면, 컨텍스츄얼 로깅을 지원하는 쿠버네티스 구성 요소가 로그 출력에 추가 상세를 추가한다. - `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에 대한 리더 마이그레이션을 지원한다. -- `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}} - 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면, - 동일한 컨트롤러의 버전 1이 선택된다. - `CronJobTimeZone`: [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)의 선택적 `timeZone` 필드 사용을 허용한다. - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서 `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다. - `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다. -- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. - 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 - 확인한다. -- `CustomResourceDefaulting`: OpenAPI v3 유효성 검사 스키마에서 기본값에 대한 CRD 지원을 활성화한다. -- `CustomResourcePublishOpenAPI`: CRD OpenAPI 사양을 게시할 수 있다. -- `CustomResourceSubresources`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 - 생성된 리소스에서 `/status` 및 `/scale` 하위 리소스를 활성화한다. -- `CustomResourceValidation`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 - 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. -- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 - 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. - `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록 데몬셋 워크로드를 사용하도록 설정한다. [데몬셋에서 롤링 업데이트 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)을 참고한다. @@ -858,36 +531,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, hugepages 사용을 활성화한다. - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. -- `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다. - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. 이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다. 이 기능 게이트는 1.24에 kubelet에서 제거되었다. [kubelet 재구성하기](/docs/tasks/administer-cluster/reconfigure-kubelet/)를 참고한다. -- `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록 - 기본 스케줄러를 확장한다. - 이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다. -- `DynamicVolumeProvisioning`: 파드에 퍼시스턴트 볼륨의 - [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다. -- `EfficientWatchResumption`: 스토리지에서 생성된 북마크(진행 - 알림) 이벤트를 사용자에게 전달할 수 있다. 이것은 감시 작업에만 - 적용된다. -- `EnableAggregatedDiscoveryTimeout`: 수집된 검색 호출에서 5초 - 시간 초과를 활성화한다. -- `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의 - 동등성을 캐시할 수 있게 한다. -- `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 - 엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. -- `EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다. -- `EndpointSliceProxying`: 활성화되면, 리눅스에서 실행되는 - kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 - 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. - [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. - `EndpointSliceTerminatingCondition`: 엔드포인트슬라이스 `terminating` 및 `serving` 조건 필드를 활성화한다. +- `EfficientWatchResumption`: 스토리지에서 생성된 북마크(진행 알림) 이벤트를 + 사용자에게 전달할 수 있다. 이것은 감시 작업에만 적용된다. - `EphemeralContainers`: 파드를 실행하기 위한 {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를 추가할 수 있다. -- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. - [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 참고한다. +- `EventedPLEG`: kubelet이 {{}}에 대한 + 확장(extension)을 통해 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}으로부터 + 컨테이너 라이프사이클 이벤트를 받을 수 있는 기능을 + 활성화한다(PLEG는 “Pod lifecycle event generator”의 약자). + 이 기능이 효과적이려면, + 클러스터에서 실행되는 각 컨테이너 런타임의 컨테이너 라이프사이클 이벤트 기능도 활성화해야 한다. + 컨테이너 런타임이 컨테이너 라이프사이클 이벤트 지원 여부를 옥시하지 않으면, + kubelet은 이 기능 게이트가 활성화되어 있더라도 자동으로 기존(legacy) 일반 PLEG 메커니즘으로 전환한다. - `ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다. 이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한 현재 수정된 결함에 의존하는 경우 존재한다. @@ -901,21 +562,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다. - `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다. -- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 - 어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. - 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. - `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. -- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 - 버그를 수정한다. -- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. -- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 - 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 - 등에서 제공할 수 있음). - [임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/)을 참고한다. - `GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행 중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 @@ -933,26 +584,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 개별 컨테이너 메트릭을 기반으로 확장한다. - `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해 `minReplicas` 를 0으로 설정한다. -- `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 - 할당 및 사용을 활성화한다. -- `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 - 여러 크기를 지원한다. -- `HyperVContainer`: 윈도우 컨테이너를 위한 - [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) - 기능을 활성화한다. +- `IPTablesOwnershipCleanup`: 이를 활성화하면 kubelet이 더 이상 레거시 IPTables 규칙을 만들지 않는다. - `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. 쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다. -- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 - 변경할 수 없는(immutable) 것으로 표시할 수 있다. - `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를 완료 인덱스에 따라 관리할 수 있도록 허용한다. -- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 - `IngressClass` 리소스를 참조할 수 있도록 허용한다. - 이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다. -- `Initializers`: Initializers 어드미션 플러그인을 사용하여, - 오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다. - `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 플러그인의 등록을 중지한다. - `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 @@ -969,11 +607,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 플러그인의 등록을 중지한다. - `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 플러그인의 등록을 중지한다. -- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) - 기능을 활성화한다. - `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 파드 템플릿에 있는 노드 스케줄링 지시를 업데이트할 수 있게 한다. -- `JobPodFailurePolicy`: 사용자가 컨테이너의 종료 코드나 파드 상태에 따라 파드의 장애를 처리할 수 있도록 한다. +- `JobPodFailurePolicy`: 사용자가 컨테이너의 종료 코드나 파드 상태에 따라 + 파드의 장애를 처리할 수 있도록 한다. - `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)이 `Ready`인 파드의 수를 추적하는 기능을 활성화한다. `Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의 @@ -983,17 +620,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, [잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다. 잡 컨트롤러는 완료된 파드를 추적하기 위해 완료된 파드의 잡 상태 필드를 사용한다. -- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 - kubelet 구성을 로드할 수 있다. - 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 - 참고한다. +- `KMSv2`: 저장 데이터 암호화(encryption at rest)를 위한 KMS v2 API를 활성화한다. 더 자세한 정보는 [KMS 공급자를 사용하여 데이터 암호화하기](/docs/tasks/administer-cluster/kms-provider/)를 참고한다. - `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 엔드포인트를 활성화한다. 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을 참고한다. @@ -1002,15 +634,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를 [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다. -- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 - `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 - `node-role.kubernetes.io/master` 레이블을 무시한다. - `KubeletTracing`: kubelet에 분산 추적에 대한 지원을 추가한다. 활성화된 경우, kubelet CRI 인터페이스와 인증된 http 서버들은 OpenTelemetry 추적 범위를 형성하는 데 도움을 준다. 자세한 내용은 [쿠버네티스 시스템 컴포넌트에 대한 추적](/ko/docs/concepts/cluster-administration/system-traces/) 페이지를 확인한다. - `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 자동 생성을 중단한다. +- `LegacyServiceAccountTokenTracking`: 시크릿 기반 + [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 사용을 추적한다. - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 @@ -1038,21 +669,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, `minDomains` 사용을 활성화한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. -- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. -- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. - 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. -- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) - {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. - (네임스페이스의 이름도 변경 불가) +- `MultiCIDRRangeAllocator`: MultiCIDR 범위 할당기를 활성화한다. - `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. - `NetworkPolicyStatus`: 네트워크폴리시 오브젝트에 대해 `status` 서브리소스를 활성화한다. - `NodeInclusionPolicyInPodTopologySpread`: 파드 토폴로지 분배 비대칭도를 계산할 때 [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)의 `nodeAffinityPolicy`와 `nodeTaintsPolicy`를 활성화한다. -- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` - 사용을 활성화한다. -- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. - `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면, 노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며, 종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다. @@ -1064,30 +687,21 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의 "enum" 필드 채우기를 활성화한다. - `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다. +- `PDBUnhealthyPodEvictionPolicy`: `PodDisruptionBudget`의 `unhealthyPodEvictionPolicy` 필드를 활성화한다. + 비정상(unhealthy) 파드가 어느 시점에 축출 대상이 될지를 이 필드에 명시한다. + 더 자세한 정보는 [비정상 파드 축출 정책](/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy)을 참고한다. - `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록, [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다. -- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. - `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. - `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다. - `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드에 대한 통계치들을 cAdvisor가 아닌 CRI 컨테이너 런타임으로부터 수집하도록 설정한다. -- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. - `PodDisruptionConditions`: 중단(disruption)으로 인해 파드가 삭제되고 있음을 나타내는 파드 컨디션을 추가하도록 지원한다. - `PodHasNetworkCondition`: kubelet이 파드에 [파드 네트워크 준비성](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-has-network) 컨디션을 표시하도록 지원한다. -- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) - 기능을 활성화한다. -- `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 - 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. -- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 - `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 - 참고한다. +- `PodSchedulingReadiness`: 파드의 [스케줄링 준비성](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)을 제어할 수 있도록 `schedulingGates` 필드를 활성화한다. - `PodSecurity`: `PodSecurity` 어드미션 플러그인을 사용하도록 설정한다. -- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 - 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 - [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. - `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에 지정된 노드를 먼저 검사할지 여부를 스케줄러에 알려준다. @@ -1099,8 +713,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 컨테이너의 proc 타입의 마운트를 제어할 수 있다. - `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록 kube-proxy를 활성화한다. -- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 - 삭제되지 않도록 한다. - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다 (현재 메모리만 해당). @@ -1117,38 +729,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 이 필드는 쿠버네티스 v1.16에서 사용 중단되었다. 이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만, 항상 빈 칸으로 유지된다. -- `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을 - 관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다. -- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 - 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 - 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 - 노드 사이의 관계를 끊는 것이다. -- `ResourceQuotaScopeSelectors`: 리소스 쿼터 범위 셀렉터를 활성화한다. -- `RootCAConfigMap`: 모든 네임스페이스에 `kube-root-ca.crt`라는 - {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 게시하도록 - `kube-controller-manager` 를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 - 사용되는 CA 번들이 포함되어 있다. 자세한 내용은 - [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 - 참조한다. -- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. - 자세한 내용은 - [kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. +- `RetroactiveDefaultStorageClass`: 연결이 해제된(unbound) PVC에 스토리지클래스를 소급적으로 할당하는 것을 허용한다. - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. 자세한 사항은 [kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다. -- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 - 활성화한다. -- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) - 기능을 활성화한다. -- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 - 스케줄링할 수 있다. -- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 - _SCTP_ `protocol` 값을 활성화한다. +- `SELinuxMountReadWriteOncePod`: kubelet으로 하여금, + 볼륨에 있는 모든 파일에 대해 SELinux 레이블을 재귀적으로 적용하는 대신 + 올바른 SELinux 레이블을 가지고 볼륨을 마운트할 수 있도록 한다. - `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다. seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다. -- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여 - 목록 작업을 가속화할 수 있다. - `SELinuxMountReadWriteOncePod`: kubelet으로 하여금, 볼륨에 있는 모든 파일에 대해 SELinux 레이블을 재귀적으로 적용하는 대신 올바른 SELinux 레이블을 가지고 볼륨을 마운트할 수 있도록 한다. @@ -1157,75 +747,31 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다. 이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라 API 서버 사이드에서 수행됨을 의미한다. -- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 - JWKS URL)를 활성화한다. 자세한 내용은 - [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 - 참고한다. -- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다. - `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다. - `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다. - `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은 [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다. -- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. -- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 - 제외할 수 있다. "`node.kubernetes.io/exclude-from-external-load-balancers`"로 - 레이블이 지정된 경우 노드를 제외할 수 있다. -- `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 - 있도록 한다. 자세한 내용은 - [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 - 참고한다. - `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는 서비스 ClusterIP 할당 전략을 활성화한다. ClusterIP 동적 할당을 주로 상위 범위에서 수행하여, 사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다. 더 자세한 사항은 [충돌 방지](/ko/docs/concepts/services-networking/service/#avoiding-collisions)를 참고한다. -- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 - 설정하는 기능을 활성화한다. - [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다. - `SizeMemoryBackedVolumes`: memory-backed 볼륨(보통 `emptyDir` 볼륨)의 크기 상한을 지정할 수 있도록 kubelets를 활성화한다. -- `StartupProbe`: kubelet에서 - [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) - 프로브를 활성화한다. - `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를 반영할 수 있다. -- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 - 사용 중인 경우 삭제를 연기한다. +- `StatefulSetStartOrdinal`: 스테이트풀셋 내에서 시작 서수(start ordinal)를 설정할 수 있도록 한다. + 더 자세한 내용은 + [시작 서수](/ko/docs/concepts/workloads/controllers/statefulset/#시작-서수)를 + 확인한다. - `StorageVersionAPI`: [스토리지 버전 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageversion-v1alpha1-internal-apiserver-k8s-io)를 활성화한다. - `StorageVersionHash`: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록 허용한다. -- `StreamingProxyRedirects`: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을 - 가로채서 따르도록 API 서버에 지시한다. - 스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다. -- `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. - 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. -- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. - `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` - 파라미터를 지정하여 지정된 수의 프로세스 ID가 - 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 - 할 수 있다. -- `SupportPodPidsLimit`: 파드의 PID 제한에 대한 지원을 활성화한다. - `SuspendJob`: 잡 중지/재시작 기능을 활성화한다. - 자세한 내용은 [잡 문서](/ko/docs/concepts/workloads/controllers/job/)를 - 참고한다. -- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 - 파라미터(sysctl)를 지원한다. 자세한 내용은 - [sysctl](/ko/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. -- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 - 실행이 끝난 후 리소스를 정리하도록 - 허용한다. -- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 - 노드에서 파드를 축출할 수 있다. - 자세한 내용은 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 - 참고한다. -- `TaintNodesByCondition`: [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)을 - 기반으로 자동 테인트 노드를 활성화한다. -- `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다. -- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해 - 서비스 어카운트 토큰을 파드에 주입할 수 있다. + 자세한 내용은 [잡 문서](/ko/docs/concepts/workloads/controllers/job/)를 참고한다. - `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반 토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은 [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/) @@ -1233,34 +779,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다. -- `ValidateProxyRedirects`: 이 플래그는 API 서버가 동일한 호스트로만 리디렉션되는가를 - 확인해야 하는지 여부를 제어한다. `StreamingProxyRedirects` - 플래그가 활성화된 경우에만 사용된다. +- `TopologyManagerPolicyAlphaOptions`: 토폴로지 매니저 폴리시(topology manager + policy)의 실험적이고 알파 품질인 옵션의 미세 조정 기능을 활성화한다. + 이 기능 게이트는 품질 수준이 알파 상태인 토폴로지 매니저 옵션 *군*을 제어한다. + 이 기능 게이트는 앞으로도 베타 또는 안정 상태로 승급되지 않는다. +- `TopologyManagerPolicyBetaOptions`: 토폴로지 매니저 폴리시(topology manager + policy)의 실험적이고 베타 품질인 옵션의 미세 조정 기능을 활성화한다. + 이 기능 게이트는 품질 수준이 베타 상태인 토폴로지 매니저 옵션 *군*을 제어한다. + 이 기능 게이트는 앞으로도 안정 상태로 승급되지 않는다. +- `TopologyManagerPolicyOptions`: 토폴로지 매니저 폴리시(topology manager policy)의 미세 조정 기능을 활성화한다. +- `UserNamespacesStatelessPodsSupport`: 스테이트리스(stateless) 파드에 대한 유저 네임스페이스 지원 기능을 활성화한다. +- `ValidatingAdmissionPolicy`: 어드미션 컨트롤에 CEL(Common Expression Language) 검증을 사용할 수 있도록 하는 [ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/) 지원 기능을 활성화한다. - `VolumeCapacityPriority`: 가용 PV 용량을 기반으로 여러 토폴로지에 있는 노드들의 우선순위를 정하는 기능을 활성화한다. -- `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다. -- `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고 - 퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한 - `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때 - [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다. -- `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다. -- `VolumeSubpath`: 컨테이너에 볼륨의 하위 경로(subpath)를 마운트할 수 있다. -- `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해 - `subPathExpr` 필드를 활성화한다. -- `WarningHeaders`: API 응답에서 경고 헤더를 보낼 수 있다. - `WatchBookmark`: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다. - `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다. - `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다. -- `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는 - 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 - 확장성과 성능을 향상시킨다. - [엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. -- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다. - `WindowsHostProcessContainers`: 윈도우 HostProcess 컨테이너에 대한 지원을 사용하도록 설정한다. -- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 - 애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은 - [RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을 - 참고한다. ## {{% heading "whatsnext" %}} From 5c6199cb0c869d4a5e396c516f021af2cd25134a Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 2 Feb 2023 17:53:30 +0900 Subject: [PATCH 14/69] [ko] Update outdated files in dev-1.26-ko.1 M67 --- .../concepts/services-networking/service.md | 689 ++++++------------ .../ko/docs/reference/networking/_index.md | 11 + .../{ => networking}/ports-and-protocols.md | 2 +- .../reference/networking/service-protocols.md | 122 ++++ .../docs/reference/networking/virtual-ips.md | 284 ++++++++ 5 files changed, 629 insertions(+), 479 deletions(-) create mode 100644 content/ko/docs/reference/networking/_index.md rename content/ko/docs/reference/{ => networking}/ports-and-protocols.md (99%) create mode 100644 content/ko/docs/reference/networking/service-protocols.md create mode 100644 content/ko/docs/reference/networking/virtual-ips.md diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 21bb82f919..bfba8f7ab0 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -6,7 +6,9 @@ feature: title: 서비스 디스커버리와 로드 밸런싱 description: > 쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다. 쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다. - +description: >- + 외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며, + 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다. content_type: concept weight: 10 --- @@ -59,9 +61,10 @@ _서비스_ 로 들어가보자. ### 클라우드-네이티브 서비스 디스커버리 -애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우, -서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 -질의할 수 있다. +애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우, +매치되는 엔드포인트슬라이스를 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 질의할 수 있다. +쿠버네티스는 서비스의 파드가 변경될 때마다 서비스의 엔드포인트슬라이스를 업데이트한다. 네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드 밸런서를 배치할 수 있는 방법을 제공한다. @@ -149,8 +152,9 @@ spec: 예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다. -서비스의 기본 프로토콜은 TCP이다. 다른 -[지원되는 프로토콜](#protocol-support)을 사용할 수도 있다. +서비스의 기본 프로토콜은 +[TCP](/docs/reference/networking/service-protocols/#protocol-tcp)이다. +다른 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다. 많은 서비스가 하나 이상의 포트를 노출해야 하기 때문에, 쿠버네티스는 서비스 오브젝트에서 다중 포트 정의를 지원한다. @@ -159,8 +163,12 @@ spec: ### 셀렉터가 없는 서비스 서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만, -셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며, -여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다. +셀렉터 대신 매칭되는(corresponding) +{{}} +오브젝트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며, +여기에는 클러스터 외부에서 실행되는 것도 포함된다. + +예시는 다음과 같다. * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만, 테스트 환경에서는 자체 데이터베이스를 사용한다. @@ -169,7 +177,7 @@ spec: * 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안, 쿠버네티스에서는 백엔드의 일부만 실행한다. -이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다. +이러한 시나리오에서는 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다. 예를 들면 ```yaml @@ -184,29 +192,41 @@ spec: targetPort: 9376 ``` -이 서비스에는 셀렉터가 없으므로, 해당 엔드포인트 오브젝트가 자동으로 -생성되지 않는다. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에 -서비스를 수동으로 매핑할 수 있다. +이 서비스에는 셀렉터가 없으므로, 매칭되는 엔드포인트슬라이스 +(및 레거시 엔드포인트) 오브젝트가 자동으로 생성되지 않는다. +엔드포인트슬라이스 오브젝트를 수동으로 추가하여, +서비스를 실행 중인 네트워크 주소 및 포트에 서비스를 수동으로 매핑할 수 있다. 예시는 다음과 같다. ```yaml -apiVersion: v1 -kind: Endpoints +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice metadata: - # 여기서의 이름은 서비스의 이름과 일치해야 한다. - name: my-service -subsets: + name: my-service-1 # 관행적으로, 서비스의 이름을 + # 엔드포인트슬라이스 이름의 접두어로 사용한다. + labels: + # "kubernetes.io/service-name" 레이블을 설정해야 한다. + # 이 레이블의 값은 서비스의 이름과 일치하도록 지정한다. + kubernetes.io/service-name: my-service +addressType: IPv4 +ports: + - name: '' # 9376 포트는 (IANA에 의해) 잘 알려진 포트로 할당되어 있지 않으므로 + # 이 칸은 비워 둔다. + appProtocol: http + protocol: TCP + port: 9376 +endpoints: - addresses: - - ip: 192.0.2.42 - ports: - - port: 9376 + - "10.4.5.6" # 이 목록에 IP 주소를 기재할 때 순서는 상관하지 않는다. + - "10.1.2.3" ``` -엔드포인트 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +#### 커스텀 엔드포인트슬라이스 -서비스를 위한 객체인 [엔드포인트](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)를 만들 때, -새로운 객체의 이름을 -그것의 서비스 이름과 같게 설정해야 한다. +서비스를 위한 [엔드포인트슬라이스](#엔드포인트슬라이스) 오브젝트를 생성할 때, +엔드포인트슬라이스 이름으로는 원하는 어떤 이름도 사용할 수 있다. +네임스페이스 내의 각 엔드포인트슬라이스 이름은 고유해야 한다. +해당 엔드포인트슬라이스에 `kubernetes.io/service-name` {{< glossary_tooltip text="레이블" term_id="label" >}}을 설정하여 +엔드포인트슬라이스를 서비스와 연결할 수 있다. {{< note >}} 엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는 @@ -217,204 +237,94 @@ subsets: 목적지(destination)로 지원하지 않기 때문이다. {{< /note >}} -셀렉터가 없는 서비스에 접근하면 셀렉터가 있는 것처럼 동일하게 작동한다. -위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로 -라우팅된다. `192.0.2.42:9376` (TCP) +직접 생성했거나 직접 작성한 코드에 의해 생성된 엔드포인트슬라이스를 위해, +[`endpointslice.kubernetes.io/managed-by`](/ko/docs/reference/labels-annotations-taints/#endpointslicekubernetesiomanaged-by) +레이블에 사용할 값을 골라야 한다. +엔드포인트슬라이스를 관리하는 컨트롤러 코드를 직접 작성하는 경우, +`"my-domain.example/name-of-controller"`와 같은 값을 사용할 수 있다. +써드파티 도구를 사용하는 경우, 도구의 이름에서 대문자는 모두 소문자로 바꾸고 +공백 및 다른 문장 부호는 하이픈(`-`)으로 대체한 문자열을 사용한다. +`kubectl`과 같은 도구를 사용하여 직접 엔드포인트슬라이스를 관리하는 경우, +`"staff"` 또는 `"cluster-admins"`와 같이 이러한 수동 관리를 명시하는 이름을 사용한다. +쿠버네티스 자체 컨트롤 플레인이 관리하는 엔드포인트슬라이스를 가리키는 +`"controller"`라는 예약된 값은 사용하지 말아야 한다. -{{< note >}} -쿠버네티스 API 서버는 파드에 매핑되지 않은 엔드포인트를 프록시하는 것을 허용하지 않는다. -셀렉터가 없는 서비스에 대해서 `kubectl proxy `과 같은 행위는 -이런 제약으로 인해 실패할 것이다. 이는 사용자가 쿠버네티스 API 서버를 -프록시로 사용하여 허가받지 않은 엔드포인트에 접근하는 것을 막아준다. -{{< /note >}} +#### 셀렉터가 없는 서비스에 접근하기 {#service-no-selector-access} -ExternalName 서비스는 셀렉터가 없고 -DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은 -이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다. +셀렉터가 없는 서비스에 접근하는 것은 셀렉터가 있는 서비스에 접근하는 것과 동일하게 동작한다. +셀렉터가 없는 서비스 [예시](#services-without-selectors)에서, 트래픽은 +엔드포인트슬라이스 매니페스트에 정의된 두 엔드포인트 중 하나로 라우트된다(10.1.2.3:9376 또는 10.4.5.6:9376으로의 TCP 연결). -### 초과 용량 엔드포인트 -엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상) -클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다. -이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며 -엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다. +ExternalName 서비스는 셀렉터가 없고 +대신 DNS 이름을 사용하는 특이 케이스 서비스이다. +자세한 내용은 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다. ### 엔드포인트슬라이스 {{< feature-state for_k8s_version="v1.21" state="stable" >}} -엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는 -API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를 -사용하면 여러 리소스에 네트워크 엔드포인트를 분산시킬 수 있다. 기본적으로, -엔드포인트슬라이스는 100개의 엔드포인트에 도달하면 "가득찬 것"로 간주되며, -추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트슬라이스가 -생성된다. +[엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)는 +특정 서비스의 하위(backing) 네트워크 엔드포인트 부분집합(_슬라이스_)을 나타내는 오브젝트이다. -엔드포인트슬라이스는 [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서 -자세하게 설명된 추가적인 속성 및 기능을 제공한다. +쿠버네티스 클러스터는 각 엔드포인트슬라이스가 얼마나 많은 엔드포인트를 나타내는지를 추적한다. +한 서비스의 엔드포인트가 너무 많아 역치에 도달하면, +쿠버네티스는 빈 엔드포인트슬라이스를 생성하고 여기에 새로운 엔드포인트 정보를 저장한다. +기본적으로, 쿠버네티스는 기존의 모든 엔드포인트슬라이스가 +엔드포인트를 최소 100개 이상 갖게 되면 새 엔드포인트슬라이스를 생성한다. +쿠버네티스는 새 엔드포인트가 추가되어야 하는 상황이 아니라면 +새 엔드포인트슬라이스를 생성하지 않는다. + +이 API에 대한 더 많은 정보는 +[엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. + +### 엔드포인트 + +쿠버네티스 API에서, +[엔드포인트(Endpoints)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)(리소스 명칭이 복수형임)는 +네트워크 엔드포인트의 목록을 정의하며, +일반적으로 트래픽이 어떤 파드에 보내질 수 있는지를 정의하기 위해 서비스가 참조한다. + +엔드포인트 대신 엔드포인트슬라이스 API를 사용하는 것을 권장한다. + +#### 용량 한계를 넘어선 엔드포인트 + +쿠버네티스는 단일 엔드포인트(Endpoints) 오브젝트에 포함될 수 있는 엔드포인트(endpoints)의 수를 제한한다. +단일 서비스에 1000개 이상의 하위(backing) 엔드포인트가 있으면, +쿠버네티스는 엔드포인트 오브젝트의 데이터를 덜어낸다(truncate). +서비스는 하나 이상의 엔드포인트슬라이스와 연결될 수 있기 때문에, +하위 엔드포인트 1000개 제한은 기존(legacy) 엔드포인트 API에만 적용된다. + +이러한 경우, 쿠버네티스는 엔드포인트(Endpoints) 오브젝트에 저장될 수 있는 +백엔드 엔드포인트(endpoints)를 최대 1000개 선정하고, +엔드포인트 오브젝트에 [`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity) +{{< glossary_tooltip text="어노테이션" term_id="annotation" >}}을 설정한다. +컨트롤 플레인은 또한 백엔드 파드 수가 1000 미만으로 내려가면 +해당 어노테이션을 제거한다. + +트래픽은 여전히 백엔드로 전송되지만, 기존(legacy) 엔드포인트 API에 의존하는 모든 로드 밸런싱 메커니즘은 +사용 가능한 하위(backing) 엔드포인트 중에서 최대 1000개까지에만 트래픽을 전송한다. + +동일한 API 상한은 곧 하나의 엔드포인트(Endpoints) 객체가 1000개 이상의 엔드포인트(endpoints)를 갖도록 수동으로 업데이트할 수는 없음을 의미한다. ### 애플리케이션 프로토콜 {{< feature-state for_k8s_version="v1.20" state="stable" >}} `appProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다. -이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 +이 필드의 값은 상응하는 엔드포인트와 엔드포인트슬라이스 오브젝트에 의해 미러링된다. 이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은 [IANA 표준 서비스 이름](https://www.iana.org/assignments/service-names) 또는 `mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다. -## 가상 IP와 서비스 프록시 - -쿠버네티스 클러스터의 모든 노드는 `kube-proxy`를 실행한다. `kube-proxy`는 -[`ExternalName`](#externalname) 이외의 유형의 `서비스`에 대한 -가상 IP 형식을 구현한다. - -### 라운드-로빈 DNS를 사용하지 않는 이유 - -항상 발생하는 질문은 왜 쿠버네티스가 인바운드 트래픽을 백엔드로 전달하기 위해 프록시에 -의존하는가 하는 점이다. 다른 접근법이 -있는가? 예를 들어, 여러 A 값 (또는 IPv6의 경우 AAAA)을 가진 -DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 -취할 수 있는가? - -서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다. - -* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를 - 캐싱하는 DNS 구현에 대한 오래된 역사가 있다. -* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다. -* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이 - 낮거나 0이면 DNS에 부하가 높아 관리하기가 - 어려워 질 수 있다. - -본 페이지의 뒷 부분에서 다양한 kube-proxy 구현이 동작하는 방식에 대해 읽을 수 있다. -우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이 -수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고, -이는 때로는 리부트 전까지 정리되지 않을 수도 있다. -그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹 -프록시 서비스가 구동됨으로써 발생하는 결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다. -비록 `kube-proxy` 실행 파일이 `cleanup` 기능을 지원하기는 하지만, 이 기능은 공식적인 기능이 -아니기 때문에 구현된 그대로만 사용할 수 있다. - -### 구성 - -kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다. -- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 - 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다. -- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다. -- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. - 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, - 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. - 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, - 윈도우 유저스페이스 모드로는 기동하지 않을 것이다. - -### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace} - -이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의 -추가와 제거를 감시한다. 각 서비스는 로컬 노드에서 -포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든 -연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다. -kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 -`SessionAffinity` 설정을 고려한다. - -마지막으로, 유저-스페이스 프록시는 서비스의 -`clusterIP` (가상)와 `port` 에 대한 트래픽을 캡처하는 iptables 규칙을 설치한다. 이 규칙은 -트래픽을 백엔드 파드를 프록시하는 프록시 포트로 리다이렉션한다. - -기본적으로, 유저스페이스 모드의 kube-proxy는 라운드-로빈 알고리즘으로 백엔드를 선택한다. - -![유저스페이스 프록시에 대한 서비스 개요 다이어그램](/images/docs/services-userspace-overview.svg) - -### `iptables` 프록시 모드 {#proxy-mode-iptables} - -이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스, 엔드포인트 오브젝트의 -추가와 제거를 감시한다. 각 서비스에 대해, 서비스의 -`clusterIP` 및 `port`에 대한 트래픽을 캡처하고 해당 트래픽을 서비스의 -백엔드 세트 중 하나로 리다이렉트(redirect)하는 -iptables 규칙을 설치한다. 각 엔드포인트 오브젝트에 대해, -백엔드 파드를 선택하는 iptables 규칙을 설치한다. - -기본적으로, iptables 모드의 kube-proxy는 임의의 백엔드를 선택한다. - -트래픽을 처리하기 위해 iptables를 사용하면 시스템 오버헤드가 줄어드는데, 유저스페이스와 -커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 트래픽을 처리하기 -때문이다. 이 접근 방식은 더 신뢰할 수 있기도 하다. - -kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드가 -응답하지 않으면, 연결이 실패한다. 이는 userspace 모드와 -다르다. 해당 시나리오에서는, kube-proxy는 첫 번째 -파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다. - -파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여 -백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는 -정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해 -실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다. - -![iptables 프록시에 대한 서비스 개요 다이어그램](/images/docs/services-iptables-overview.svg) - -### IPVS 프록시 모드 {#proxy-mode-ipvs} - -{{< feature-state for_k8s_version="v1.11" state="stable" >}} - -`ipvs` 모드에서는, kube-proxy는 쿠버네티스 서비스와 엔드포인트를 감시하고, -`netlink` 인터페이스를 호출하여 그에 따라 IPVS 규칙을 생성하고 -IPVS 규칙을 쿠버네티스 서비스와 엔드포인트와 주기적으로 동기화한다. -이 제어 루프는 IPVS 상태가 원하는 상태와 일치하도록 -보장한다. -서비스에 접근하면, IPVS는 트래픽을 백엔드 파드 중 하나로 보낸다. - -IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을 -기반으로 하지만, 해시 테이블을 기본 데이터 구조로 사용하고 -커널 스페이스에서 동작한다. -이는 IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다 -지연 시간이 짧은 트래픽을 리다이렉션하고, 프록시 규칙을 동기화할 때 성능이 -훨씬 향상됨을 의미한다. 다른 프록시 모드와 비교했을 때, IPVS 모드는 -높은 네트워크 트래픽 처리량도 지원한다. - -IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다. -다음과 같다. - -* `rr`: 라운드-로빈 -* `lc`: 최소 연결 (가장 적은 수의 열려있는 연결) -* `dh`: 목적지 해싱 -* `sh`: 소스 해싱 -* `sed`: 최단 예상 지연 (shortest expected delay) -* `nq`: 큐 미사용 (never queue) - -{{< note >}} -IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를 -사용 가능하도록 해야 한다. - -kube-proxy가 IPVS 프록시 모드에서 시작될 때, IPVS 커널 모듈을 -사용할 수 있는지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는 -iptables 프록시 모드에서 다시 실행된다. -{{< /note >}} - -![IPVS 프록시에 대한 서비스 개요 다이어그램](/images/docs/services-ipvs-overview.svg) - -이 프록시 모델에서 클라이언트가 쿠버네티스 또는 서비스 또는 파드에 -대해 알지 못하는 경우 서비스의 IP:포트로 향하는 트래픽은 -적절한 백엔드로 프록시된다. - -특정 클라이언트의 연결이 매번 동일한 파드로 -전달되도록 하려면, `service.spec.sessionAffinity`를 "ClientIP"로 설정하여 -클라이언트의 IP 주소를 기반으로 세션 어피니티(Affinity)를 선택할 수 있다. -(기본값은 "None") -`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 적절히 설정하여 -최대 세션 고정 시간을 설정할 수도 있다. -(기본값은 10800으로, 3시간) - -{{< note >}} -윈도우에서, 서비스들의 최대 세션 고정 시간(maximum session sticky time)을 설정하는 것은 지원되지 않는다. -{{< /note >}} - ## 멀티-포트 서비스 일부 서비스의 경우, 둘 이상의 포트를 노출해야 한다. 쿠버네티스는 서비스 오브젝트에서 멀티 포트 정의를 구성할 수 있도록 지원한다. 서비스에 멀티 포트를 사용하는 경우, 모든 포트 이름을 명확하게 지정해야 한다. -예를 들면 +예를 들면 다음과 같다. ```yaml apiVersion: v1 @@ -455,40 +365,6 @@ 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는 트래픽을 포워드하지 않는다. - ## 서비스 디스커버리하기 쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경 @@ -571,50 +447,57 @@ DNS SRV 쿼리를 수행할 수 있다. ### 셀렉터가 있는 경우 -셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는 -API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여 -`서비스` 를 지원하는 `파드` 를 직접 가리키는 A 레코드(IP 주소)를 반환한다. +셀렉터를 정의하는 헤드리스 서비스의 경우, 쿠버네티스 컨트롤 플레인은 +쿠버네티스 API 내에서 엔드포인트슬라이스 오브젝트를 생성하고, +서비스 하위(backing) 파드들을 직접 가리키는 +A 또는 AAAA 레코드(IPv4 또는 IPv6 주소)를 반환하도록 DNS 구성을 변경한다. ### 셀렉터가 없는 경우 -셀렉터를 정의하지 않는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는 -`엔드포인트` 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고 -구성한다. +셀렉터를 정의하지 않는 헤드리스 서비스의 경우, +쿠버네티스 컨트롤 플레인은 엔드포인트슬라이스 오브젝트를 생성하지 않는다. +하지만, DNS 시스템은 다음 중 하나를 탐색한 뒤 구성한다. -* [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드 -* 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에 - 대한 레코드 +* [`type: ExternalName`](#externalname) 서비스에 대한 DNS CNAME 레코드 +* `ExternalName` 이외의 모든 서비스 타입에 대해, + 서비스의 활성(ready) 엔드포인트의 모든 IP 주소에 대한 DNS A / AAAA 레코드 + * IPv4 엔드포인트에 대해, DNS 시스템은 A 레코드를 생성한다. + * IPv6 엔드포인트에 대해, DNS 시스템은 AAAA 레코드를 생성한다. ## 서비스 퍼블리싱 (ServiceTypes) {#publishing-services-service-types} 애플리케이션 중 일부(예: 프론트엔드)는 서비스를 클러스터 밖에 위치한 외부 IP 주소에 노출하고 싶은 경우가 있을 것이다. -쿠버네티스 `ServiceTypes`는 원하는 서비스 종류를 지정할 수 있도록 해준다. -기본 값은 `ClusterIP`이다. +쿠버네티스 `ServiceTypes`는 원하는 서비스 종류를 지정할 수 있도록 해 준다. `Type` 값과 그 동작은 다음과 같다. -* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면 - 클러스터 내에서만 서비스에 도달할 수 있다. 이것은 - `ServiceTypes`의 기본 값이다. -* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를 - 노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가 - 자동으로 생성된다. `:`를 요청하여, - 클러스터 외부에서 - `NodePort` 서비스에 접속할 수 있다. +* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. + 이 값을 선택하면 클러스터 내에서만 서비스에 도달할 수 있다. + 이것은 서비스의 `type`을 명시적으로 지정하지 않았을 때의 기본값이다. +* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 + 서비스를 노출시킨다. 노드 포트를 사용할 수 있도록 하기 위해, + 쿠버네티스는 `type: ClusterIP`인 서비스를 요청했을 때와 마찬가지로 + 클러스터 IP 주소를 구성한다. * [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여 - 서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는 - `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다. -* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를 - `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에 - 매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다. - {{< note >}}`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 - CoreDNS 버전 1.7 이상이 필요하다. + 서비스를 외부에 노출시킨다. +* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, + 서비스를 `externalName` 필드의 내용(예:`foo.bar.example.com`)에 매핑한다. + 어떠한 종류의 프록시도 설정되지 않는다. + {{< note >}} + `ExternalName` 유형을 사용하려면 `kube-dns` 버전 1.7 또는 + CoreDNS 버전 0.0.8 이상이 필요하다. {{< /note >}} +`type` 필드는 중첩(nested) 기능으로 설계되어, 각 단계는 이전 단계에 더해지는 형태이다. +이는 모든 클라우드 공급자에 대해 엄격히 요구되는 사항은 아니다(예: +Google Compute Engine에서는 `type: LoadBalancer`가 동작하기 위해 노드 포트를 할당할 필요가 없지만, +다른 클라우드 공급자 통합 시에는 필요할 수 있음). +엄격한 중첩이 필수 사항은 아니지만, 서비스에 대한 쿠버네티스 API 디자인은 이와 상관없이 엄격한 중첩 구조를 가정한다. + [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. -인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. +인그레스는 서비스 유형은 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다. @@ -625,38 +508,28 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다. 서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다. -포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한 -`--nodeport-addresses` 플래그 또는 -[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에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. -(이는 이전 쿠버네티스 릴리스와도 호환된다). - -특정 포트 번호를 원한다면, `nodePort` 필드에 값을 지정할 수 -있다. 컨트롤 플레인은 해당 포트를 할당하거나 API 트랜잭션이 -실패했다고 보고한다. -이는 사용자 스스로 포트 충돌의 가능성을 고려해야 한다는 의미이다. -또한 NodePort 사용을 위해 구성된 범위 내에 있는, 유효한 포트 번호를 -사용해야 한다. - NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설정하거나, 쿠버네티스가 완벽하게 지원하지 않는 환경을 구성하거나, 하나 이상의 노드 IP를 직접 노출시킬 수 있다. -이 서비스는 `:spec.ports[*].nodePort`와 -`.spec.clusterIP:spec.ports[*].port`로 표기된다. -kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의 -동등한 필드가 설정된 경우, `` 는 노드 IP를 필터링한다. +NodePort 서비스에 대해, 쿠버네티스는 포트를 추가로 +할당한다(서비스의 프로토콜에 매치되도록 TCP, UDP, SCTP 중 하나). +클러스터의 모든 노드는 할당된 해당 포트를 리슨하고 +해당 서비스에 연결된 활성(ready) 엔드포인트 중 하나로 트래픽을 전달하도록 자기 자신을 구성한다. +적절한 프로토콜(예: TCP) 및 적절한 포트(해당 서비스에 할당된 대로)로 +클러스터 외부에서 클러스터의 아무 노드에 연결하여 `type: NodePort` 서비스로 접근할 수 있다. -예를 들면 +#### 포트 직접 선택하기 {#nodeport-custom-port} + +특정 포트 번호를 원한다면, `nodePort` 필드에 값을 명시할 수 있다. +컨트롤 플레인은 해당 포트를 할당해 주거나 또는 +해당 API 트랜젝션이 실패했다고 알려줄 것이다. +이는 사용자 스스로 포트 충돌의 가능성을 고려해야 한다는 의미이다. +또한 유효한(NodePort용으로 사용할 수 있도록 구성된 범위 내의) +포트 번호를 사용해야 한다. + +다음은 NodePort 값을 명시하는(이 예시에서는 30007) +`type: NodePort` 서비스에 대한 예시 매니페스트이다. ```yaml apiVersion: v1 @@ -676,6 +549,33 @@ spec: nodePort: 30007 ``` +#### `type: NodePort` 서비스를 위한 커스텀 IP 주소 구성 {#service-nodeport-custom-listen-address} + +NodePort 서비스 노출에 특정 IP 주소를 사용하도록 +클러스터의 노드를 설정할 수 있다. +각 노드가 여러 네트워크(예: 애플리케이션 트래픽용 네트워크 및 +노드/컨트롤 플레인 간 트래픽용 네트워크)에 연결되어 있는 경우에 이러한 구성을 고려할 수 있다. + +포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한 +`--nodeport-addresses` 플래그 또는 +[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에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. +(이는 이전 쿠버네티스 릴리스와도 호환된다). +{{< note >}} +이 서비스는 `:spec.ports[*].nodePort`와 `.spec.clusterIP:spec.ports[*].port`로 표기된다. +kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의 동등한 필드가 설정된 경우, +`` 는 노드 IP를 필터링한다. +{{< /note >}} + ### 로드밸런서 유형 {#loadbalancer} 외부 로드 밸런서를 지원하는 클라우드 공급자 상에서, `type` @@ -683,7 +583,7 @@ spec: 로드 밸런서의 실제 생성은 비동기적으로 수행되고, 프로비저닝된 밸런서에 대한 정보는 서비스의 `.status.loadBalancer` 필드에 발행된다. -예를 들면 +예를 들면 다음과 같다. ```yaml apiVersion: v1 @@ -714,6 +614,16 @@ status: 클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 `loadbalancerIP` 필드는 무시된다. +`type: LoadBalancer`인 서비스를 구현하기 위해, +쿠버네티스는 일반적으로 `type: NodePort` 서비스를 요청했을 때와 동일한 변경사항을 적용하면서 시작한다. +그런 다음 cloud-controller-manager 컴포넌트는 +할당된 해당 NodePort로 트래픽을 전달하도록 외부 로드 밸런서를 구성한다. + +_알파 기능으로서_, 로드 밸런스된 서비스가 NodePort 할당을 +[생략](#load-balancer-nodeport-allocation)하도록 구성할 수 있는데, +이는 클라우드 공급자의 구현이 이를 지원할 때에만 가능하다. + + {{< note >}} **Azure** 에서 사용자 지정 공개(public) 유형 `loadBalancerIP`를 사용하려면, 먼저 @@ -1273,211 +1183,34 @@ spec: - 80.11.12.10 ``` -## 단점 +## 세션 스티킹(stickiness) -VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의 -서비스가 포함된 대규모 클러스터로는 확장되지 않는다. -[포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이 -있다. - -유저스페이스 프록시를 사용하면 서비스에 접근하는 패킷의 소스 IP 주소가 -가려진다. -이것은 일종의 네트워크 필터링 (방화벽)을 불가능하게 만든다. iptables -프록시 모드는 클러스터 내 -소스 IP를 가리지 않지만, 여전히 로드 밸런서 또는 노드-포트를 통해 오는 -클라이언트에 영향을 미친다. - -`Type` 필드는 중첩된 기능으로 설계되었다. - 각 레벨은 이전 레벨에 -추가된다. 이는 모든 클라우드 공급자에 반드시 필요한 것은 아니지만, (예: Google Compute Engine는 -`LoadBalancer`를 작동시키기 위해 `NodePort`를 할당할 필요는 없지만, AWS는 필요하다) -현재 API에는 필요하다. - -## 가상 IP 구현 {#the-gory-details-of-virtual-ips} - -서비스를 사용하려는 많은 사람들에게 이전 정보가 -충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는 -많은 일이 있다. - -### 충돌 방지 {#avoiding-collisions} - -쿠버네티스의 주요 철학 중 하나는 잘못한 것이 -없는 경우 실패할 수 있는 상황에 노출되어서는 -안된다는 것이다. 서비스 리소스 설계 시, 다른 사람의 포트 선택과 -충돌할 경우에 대비해 자신의 포트 번호를 선택하지 -않아도 된다. 그것은 격리 실패이다. - -서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, -두 개의 서비스가 충돌하지 않도록 해야 한다. -쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서 -각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다. - -각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는 -각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서 -글로벌 할당 맵을 원자적으로(atomically) 업데이트한다. 서비스가 IP 주소 할당을 가져오려면 -레지스트리에 맵 오브젝트가 있어야 하는데, 그렇지 않으면 -IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다. - -컨트롤 플레인에서, 백그라운드 컨트롤러는 해당 맵을 -생성해야 한다. (인-메모리 잠금을 사용하는 이전 버전의 쿠버네티스에서 마이그레이션 -지원 필요함) 쿠버네티스는 또한 컨트롤러를 사용하여 유효하지 않은 -할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된 -IP 주소를 정리한다. - -#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range} - -{{< feature-state for_k8s_version="v1.25" state="beta" >}} -그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데, -그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address). -이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면 -충돌이 발생할 수 있다. - -`ServiceIPStaticSubrange` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 v1.25 이상에서 기본적으로 활성화되며, -이 때 사용하는 할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 -`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, -여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. -동적 IP 할당은 상위 대역에서 우선적으로 선택하며, -이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다. -이렇게 함으로써 사용자가 서비스의 고정 IP를 -`service-cluster-ip-range`의 하위 대역에서 할당하면서도 -충돌 위험을 줄일 수 있다. - -### 서비스 IP 주소 {#ips-and-vips} - -실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리, -서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는 -iptables (리눅스의 패킷 처리 로직)를 필요에 따라 -명백하게 리다이렉션되는 _가상_ IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에 -연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다. -환경 변수와 서비스 용 DNS는 실제로 서비스의 -가상 IP 주소 (및 포트)로 채워진다. - -kube-proxy는 조금씩 다르게 작동하는 세 가지 프록시 모드—유저스페이스, iptables and IPVS—를 -지원한다. - -#### 유저스페이스 (Userspace) - -예를 들어, 위에서 설명한 이미지 처리 애플리케이션을 고려한다. -백엔드 서비스가 생성되면, 쿠버네티스 마스터는 가상 -IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는 -클러스터의 모든 kube-proxy 인스턴스에서 관찰된다. -프록시가 새 서비스를 발견하면, 새로운 임의의 포트를 열고, 가상 IP 주소에서 -이 새로운 포트로 iptables 리다이렉션을 설정한 후, -연결을 수락하기 시작한다. - -클라이언트가 서비스의 가상 IP 주소에 연결하면, iptables -규칙이 시작되고, 패킷을 프록시의 자체 포트로 리다이렉션한다. -"서비스 프록시"는 백엔드를 선택하고, 클라이언트에서 백엔드로의 트래픽을 프록시하기 시작한다. - -이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을 -의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에 -연결할 수 있다. - -#### iptables - -다시 한번, 위에서 설명한 이미지 처리 애플리케이션을 고려한다. -백엔드 서비스가 생성되면, 쿠버네티스 컨트롤 플레인은 가상 -IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는 -클러스터의 모든 kube-proxy 인스턴스에서 관찰된다. -프록시가 새로운 서비스를 발견하면, 가상 IP 주소에서 서비스-별 규칙으로 -리다이렉션되는 일련의 iptables 규칙을 설치한다. 서비스-별 -규칙은 트래픽을 (목적지 NAT를 사용하여) 백엔드로 리다이렉션하는 엔드포인트-별 규칙에 -연결한다. - -클라이언트가 서비스의 가상 IP 주소에 연결하면 iptables 규칙이 시작한다. -(세션 어피니티(Affinity)에 따라 또는 무작위로) 백엔드가 선택되고 패킷이 -백엔드로 리다이렉션된다. 유저스페이스 프록시와 달리, 패킷은 유저스페이스로 -복사되지 않으며, 가상 IP 주소가 작동하기 위해 kube-proxy가 -실행 중일 필요는 없으며, 노드는 변경되지 않은 클라이언트 IP 주소에서 오는 -트래픽을 본다. - -트래픽이 노드-포트 또는 로드 밸런서를 통해 들어오는 경우에도, -이와 동일한 기본 흐름이 실행되지만, 클라이언트 IP는 변경된다. - -#### IPVS - -iptables 작업은 대규모 클러스터 (예: 10,000 서비스)에서 크게 느려진다. -IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이블을 기반으로 한다. -따라서 IPVS 기반 kube-proxy로부터 많은 개수의 서비스에서 일관성 있는 성능을 가질 수 있다. -한편, IPVS 기반 kube-proxy는 보다 정교한 로드 밸런싱 알고리즘 -(least conns, locality, weighted, persistence)을 가진다. +특정 클라이언트로부터의 연결이 매번 동일한 파드로 전달되도록 하고 싶다면, +클라이언트의 IP 주소 기반으로 세션 어피니티를 구성할 수 있다. +더 자세한 정보는 [세션 어피니티](/docs/reference/networking/virtual-ips/#session-affinity)를 +참고한다. ## API 오브젝트 서비스는 쿠버네티스 REST API의 최상위 리소스이다. [서비스 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)에 대한 자세한 내용을 참고할 수 있다. -## 지원되는 프로토콜 {#protocol-support} + + -### TCP +## 가상 IP 주소 메커니즘 -모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다. - -### UDP - -대부분의 서비스에 UDP를 사용할 수 있다. type=LoadBalancer 서비스의 경우, UDP 지원은 -이 기능을 제공하는 클라우드 공급자에 따라 다르다. - -### SCTP - -{{< feature-state for_k8s_version="v1.20" state="stable" >}} - -SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다. -type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는 -클라우드 공급자에 따라 다르다. (대부분 그렇지 않음) - -#### 경고 {#caveat-sctp-overview} - -##### 멀티홈드(multihomed) SCTP 연결을 위한 지원 {#caveat-sctp-multihomed} - -{{< warning >}} -멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 -멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다. - -멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다. -{{< /warning >}} - -##### 윈도우 {#caveat-sctp-windows-os} - -{{< warning >}} -SCTP는 윈도우 기반 노드를 지원하지 않는다. -{{< /warning >}} - -##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace} - -{{< warning >}} -kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다. -{{< /warning >}} - -### HTTP - -클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의 -서비스를 사용하여 서비스의 엔드포인트로 전달하는 외부 HTTP / HTTPS 리버스 프록시를 -설정할 수 있다. - -{{< note >}} -서비스 대신 {{< glossary_tooltip term_id="ingress" text="인그레스" >}} 를 사용하여 -HTTP/HTTPS 서비스를 노출할 수도 있다. -{{< /note >}} - -### PROXY 프로토콜 - -클라우드 공급자가 지원하는 경우에, -LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에 -로드 밸런서를 구성할 수 있으며, 이때 접두사가 -[PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다. - -로드 밸런서는 들어오는 연결을 설명하는 초기 일련의 -옥텟(octets)을 전송하며, 이 예와 유사하게 - -``` -PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n -``` - -클라이언트 데이터가 뒤따라온다. +[가상 IP 및 서비스 프록시](/ko/docs/reference/networking/virtual-ips/)에서 +가상 IP 주소를 갖는 서비스를 노출하기 위해 쿠버네티스가 제공하는 메커니즘에 대해 알아본다. ## {{% heading "whatsnext" %}} * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기 + +추가적으로, +* [가상 IP 및 서비스 프록시](/ko/docs/reference/networking/virtual-ips/)를 살펴보기 +* 서비스(Service) API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/service-v1/) 살펴보기 +* 엔드포인트(Endpoints) API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 살펴보기 +* 엔드포인트슬라이스 API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 살펴보기 diff --git a/content/ko/docs/reference/networking/_index.md b/content/ko/docs/reference/networking/_index.md new file mode 100644 index 0000000000..cd2194f42a --- /dev/null +++ b/content/ko/docs/reference/networking/_index.md @@ -0,0 +1,11 @@ +--- +title: 네트워킹 레퍼런스 +content_type: reference +weight: 85 +--- + + +이 섹션에서는 +쿠버네티스 네트워킹의 레퍼런스 상세를 제공한다. + + \ No newline at end of file diff --git a/content/ko/docs/reference/ports-and-protocols.md b/content/ko/docs/reference/networking/ports-and-protocols.md similarity index 99% rename from content/ko/docs/reference/ports-and-protocols.md rename to content/ko/docs/reference/networking/ports-and-protocols.md index 6ba447cda9..d86f035419 100644 --- a/content/ko/docs/reference/ports-and-protocols.md +++ b/content/ko/docs/reference/networking/ports-and-protocols.md @@ -1,7 +1,7 @@ --- title: 포트와 프로토콜 content_type: reference -weight: 50 +weight: 40 --- 물리적 네트워크 방화벽이 있는 온프레미스 데이터 센터 또는 diff --git a/content/ko/docs/reference/networking/service-protocols.md b/content/ko/docs/reference/networking/service-protocols.md new file mode 100644 index 0000000000..c2b426f922 --- /dev/null +++ b/content/ko/docs/reference/networking/service-protocols.md @@ -0,0 +1,122 @@ +--- +title: 서비스가 지원하는 프로토콜 +content_type: reference +weight: 10 +--- + + +{{< glossary_tooltip text="서비스" term_id="service" >}}를 구성하여, +쿠버네티스가 지원하는 네트워크 프로토콜 중 하나를 선택할 수 있다. + +쿠버네티스는 서비스에 대해 다음의 프로토콜을 지원한다. + +- [`SCTP`](#protocol-sctp) +- [`TCP`](#protocol-tcp) _(기본값)_ +- [`UDP`](#protocol-udp) + +서비스를 정의할 때, 서비스가 사용할 +[애플리케이션 프로토콜](/ko/docs/concepts/services-networking/service/#애플리케이션-프로토콜)을 +지정할 수도 있다. + +이 문서에서는 몇 가지 특수 사례에 대해 설명하며, +이들 모두는 일반적으로 전송 프로토콜(transport protocol)로 TCP를 사용한다. + +- [HTTP](#protocol-http-special) 및 [HTTPS](#protocol-http-special) +- [PROXY 프로토콜](#protocol-proxy-special) +- 로드밸런서에서의 [TLS](#protocol-tls-special) 터미네이션 + + +## 지원하는 프로토콜 {#protocol-support} + +서비스 포트의 `protocol`에 대해 다음 3개의 값이 유효하다. + +### `SCTP` {#protocol-sctp} + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우, 대부분의 서비스에 +SCTP를 사용할 수 있다. `type: LoadBalancer` 서비스의 경우 SCTP 지원 여부는 +이 기능을 제공하는 클라우드 공급자에 따라 다르다. (대부분 지원하지 않음) + +SCTP는 윈도우 노드에서는 지원되지 않는다. + +#### 멀티홈(multihomed) SCTP 연결 지원 {#caveat-sctp-multihomed} + +멀티홈 SCTP 연결 지원을 위해서는 CNI 플러그인이 파드에 복수개의 인터페이스 및 IP 주소를 할당하는 기능을 지원해야 한다. + +멀티홈 SCTP 연결에서의 NAT는 상응하는 커널 모듈 내의 특수한 로직을 필요로 한다. + +### `TCP` {#protocol-tcp} + +모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다. + +### `UDP` {#protocol-udp} + +대부분의 서비스에 UDP를 사용할 수 있다. `type: LoadBalancer` 서비스의 경우, +UDP 지원 여부는 이 기능을 제공하는 클라우드 공급자에 따라 다르다. + + +## 특수 케이스 + +### HTTP {#protocol-http-special} + +클라우드 공급자가 이를 지원하는 경우, +LoadBalancer 모드의 서비스를 사용하여, +쿠버네티스 클러스터 외부에, HTTP / HTTPS 리버스 프록싱을 통해 +해당 서비스의 백엔드 엔드포인트로 트래픽을 전달하는 로드밸런서를 구성할 수 있다. + +일반적으로, 트래픽을 HTTP 수준에서 제어하려면 +해당 서비스의 프로토콜을 `TCP`로 지정하고 +로드밸런서를 구성하는 +{{< glossary_tooltip text="어노테이션" term_id="annotation" >}}(보통 +클라우드 공급자마다 다름)을 추가한다. +이 구성은 워크로드로의 HTTPS (HTTP over TLS) 지원 및 평문 HTTP 리버스 프록시도 포함할 수 있다. + +{{< note >}} +서비스 대신 {{< glossary_tooltip term_id="ingress" text="인그레스" >}} 를 사용하여 +HTTP/HTTPS 서비스를 노출할 수도 있다. +{{< /note >}} + +특정 연결의 +[애플리케이션 프로토콜](/ko/docs/concepts/services-networking/service/#애플리케이션-프로토콜)을 +`http` 또는 `https`로 추가적으로 명시하고 싶을 수도 있다. +로드밸런서에서 워크로드로 가는 세션이 HTTP without TLS이면 `http`를 사용하고, +로드밸런서에서 워크로드로 가는 세션이 TLS 암호화를 사용하면 `https`를 사용한다. + +### PROXY 프로토콜 {#protocol-proxy-special} + +클라우드 공급자가 지원하는 경우에, +`type: LoadBalancer`로 설정된 서비스를 사용하여, +쿠버네티스 외부에 존재하면서 연결들을 +[PROXY 프로토콜](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt)로 감싸 전달하는 로드밸런서를 구성할 수 있다. + +이러한 로드 밸런서는 들어오는 연결을 설명하는 초기 일련의 옥텟(octets)을 전송하며, +이는 다음의 예시(PROXY 프로토콜 v1)와 유사하다. + +``` +PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n +``` + +프록시 프로토콜 프리앰블(preamble) 뒤에 오는 데이터는 +클라이언트가 전송한 원본 데이터이다. +양쪽 중 한쪽에서 연결을 닫으면, +로드밸런서도 연결 종료를 트리거하며 남아있는 데이터를 수신 가능한 쪽으로 보낸다. + +일반적으로는, 프로토콜을 `TCP`로 설정한 서비스를 정의한다. +또한, 클라우드 공급자별로 상이한 어노테이션을 설정하여 +로드밸런서가 각 인커밍 연결을 PROXY 프로토콜로 감싸도록 구성할 수도 있다. + +### TLS {#protocol-tls-special} + +클라우드 공급자가 지원하는 경우에, +`type: LoadBalancer`로 설정된 서비스를 사용하여, +쿠버네티스 외부에 존재하는 리버스 프록시를 구축할 수 있으며, +이 때 클라이언트로부터 로드밸런서까지의 연결은 TLS 암호화되고 로드밸런서는 TLS 서버 피어가 된다. +로드밸런서로부터 워크로드까지의 연결은 TLS일 수도 있으며, 평문일 수도 있다. +사용 가능한 정확한 옵션의 범위는 클라우드 공급자 또는 커스텀 서비스 구현에 따라 다를 수 있다. + +일반적으로는, 프로토콜을 `TCP`로 설정하고 +어노테이션(보통 클라우드 공급자별로 상이함)을 설정하여 +로드밸런서가 TLS 서버로 작동하도록 구성한다. +클라우드 공급자별로 상이한 메커니즘을 사용하여 +TLS 아이덴티티(서버, 그리고 경우에 따라 워크로드로 연결하는 클라이언트도 가능)를 구성할 수도 있다. diff --git a/content/ko/docs/reference/networking/virtual-ips.md b/content/ko/docs/reference/networking/virtual-ips.md new file mode 100644 index 0000000000..ad201664f1 --- /dev/null +++ b/content/ko/docs/reference/networking/virtual-ips.md @@ -0,0 +1,284 @@ +--- +title: 가상 IP 및 서비스 프록시 +content_type: reference +weight: 50 +--- + + +쿠버네티스 클러스터의 모든 {{< glossary_tooltip term_id="node" text="노드" >}}는 +[`kube-proxy`](/ko/docs/reference/command-line-tools-reference/kube-proxy/)를 +실행한다(`kube-proxy`를 대체하는 구성요소를 직접 배포한 경우가 아니라면). + +`kube-proxy`는 +[`ExternalName`](/docs/concepts/services-networking/service/#externalname) 외의 `type`의 +{{< glossary_tooltip term_id="service" text="서비스">}}를 위한 +_가상 IP_ 메커니즘의 구현을 담당한다. + + +항상 발생하는 질문은, +왜 쿠버네티스가 인바운드 트래픽을 백엔드로 전달하기 위해 +프록시에 의존하는가 하는 점이다. +다른 접근법이 있는가? 예를 들어, 여러 A 값 (또는 IPv6의 경우 AAAA)을 가진 DNS 레코드를 구성하고, +라운드-로빈 이름 확인 방식을 취할 수 있는가? + +There are a few reasons for using proxying for Services: + +* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를 캐싱하는 + DNS 구현에 대한 오래된 역사가 있다. +* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다. +* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, + DNS 레코드의 TTL이 낮거나 0이면 + DNS에 부하가 높아 관리하기가 어려워질 수 있다. + +본 페이지의 뒷 부분에서 다양한 kube-proxy 구현이 동작하는 방식에 대해 읽을 수 있다. +우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, +커널 수준의 규칙이 수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고, +이는 때로는 리부트 전까지 정리되지 않을 수도 있다. +그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹 프록시 서비스가 구동됨으로써 발생하는 +결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다. +비록 `kube-proxy` 실행 파일이 `cleanup` 기능을 지원하기는 하지만, +이 기능은 공식적인 기능이 아니기 때문에 구현된 그대로만 사용할 수 있다. + + + +예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를 생각해보자. +이러한 레플리카는 대체 가능하다. +즉, 프론트엔드는 그것들이 사용하는 백엔드를 신경쓰지 않는다. +백엔드 세트를 구성하는 실제 파드는 변경될 수 있지만, +프론트엔드 클라이언트는 이를 인식할 필요가 없으며, 백엔드 세트 자체를 추적해야 할 필요도 없다. + + + + +## 프록시 모드들 + +kube-proxy는 여러 모드 중 하나로 기동될 수 있으며, 이는 환경 설정에 따라 결정됨에 유의한다. + +- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. + 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 + 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다. +- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다. +- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. + 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, + 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. + +### `iptables` 프록시 모드 {#proxy-mode-iptables} + +이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 +서비스, 엔드포인트슬라이스 오브젝트의 추가와 제거를 감시한다. +각 서비스에 대해, 서비스의 `clusterIP` 및 `port`에 대한 트래픽을 캡처하고 +해당 트래픽을 서비스의 백엔드 세트 중 하나로 리다이렉트(redirect)하는 +iptables 규칙을 설치한다. +각 엔드포인트 오브젝트에 대해, 백엔드 파드를 선택하는 iptables 규칙을 설치한다. + +기본적으로, iptables 모드의 kube-proxy는 백엔드를 임의로 선택한다. + +트래픽을 처리하기 위해 iptables를 사용하면 시스템 오버헤드가 줄어드는데, +유저스페이스와 커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 +트래픽을 처리하기 때문이다. 이 접근 방식은 더 신뢰할 수 있기도 하다. + +kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드가 응답하지 않으면, 연결이 실패한다. +이는 이전의 `userspace` 모드와 다르다. +이전의 `userspace` 시나리오에서는, +kube-proxy는 첫 번째 파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다. + +파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여 +백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, +iptables 모드의 kube-proxy는 정상으로 테스트된 백엔드만 볼 수 있다. +이렇게 하면 트래픽이 kube-proxy를 통해 실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다. + +{{< figure src="/images/docs/services-iptables-overview.svg" title="iptables 프록시에 대한 서비스 개요 다이어그램" class="diagram-medium" >}} + +#### 예시 {#packet-processing-iptables} + +다시 한번, [위](#example)에서 설명한 +이미지 처리 애플리케이션을 고려한다. +백엔드 서비스가 생성되면, +쿠버네티스 컨트롤 플레인은 가상 IP 주소(예 : 10.0.0.1)를 할당한다. +서비스 포트를 1234라고 가정하자. +클러스터의 모든 kube-proxy 인스턴스는 +새 서비스의 생성을 관찰할 수 있다. + +프록시가 새로운 서비스를 발견하면, +가상 IP 주소에서 서비스-별 규칙으로 리다이렉션되는 일련의 iptables 규칙을 설치한다. +서비스-별 규칙은 트래픽을 (목적지 NAT를 사용하여) 백엔드로 리다이렉션하는 +엔드포인트-별 규칙에 연결한다. + +클라이언트가 서비스의 가상 IP 주소에 연결하면 iptables 규칙이 시작한다. +(세션 어피니티(Affinity)에 따라 또는 무작위로) 백엔드가 선택되고, +패킷의 클라이언트 IP 주소를 덮어쓰지 않고 백엔드로 리다이렉션된다. + +트래픽이 노드-포트 또는 로드 밸런서를 통해 들어오는 경우에도, +이와 동일한 기본 흐름이 실행되지만, 클라이언트 IP는 변경된다. + +### IPVS 프록시 모드 {#proxy-mode-ipvs} + +`ipvs` 모드에서, kube-proxy는 쿠버네티스 서비스와 엔드포인트슬라이스를 감시하고, +`netlink` 인터페이스를 호출하여 그에 따라 IPVS 규칙을 생성하고 +IPVS 규칙을 쿠버네티스 서비스 및 엔드포인트슬라이스와 주기적으로 동기화한다. +이 제어 루프는 IPVS 상태가 원하는 상태와 일치하도록 +보장한다. +서비스에 접근하면, IPVS는 트래픽을 백엔드 파드 중 하나로 보낸다. + +IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을 +기반으로 하지만, 해시 테이블을 기본 데이터 구조로 사용하고 +커널 스페이스에서 동작한다. +이는 IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다 +지연 시간이 짧은 트래픽을 리다이렉션하고, 프록시 규칙을 동기화할 때 성능이 +훨씬 향상됨을 의미한다. 다른 프록시 모드와 비교했을 때, IPVS 모드는 +높은 네트워크 트래픽 처리량도 지원한다. + +IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공하며, +그 목록은 다음과 같다. + +* `rr`: 라운드-로빈 +* `lc`: 최소 연결 (가장 적은 수의 열려있는 연결) +* `dh`: 목적지 해싱 +* `sh`: 소스 해싱 +* `sed`: 최단 예상 지연 (shortest expected delay) +* `nq`: 큐 미사용 (never queue) + +{{< note >}} +IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를 +사용 가능하도록 해야 한다. + +kube-proxy가 IPVS 프록시 모드로 시작될 때, IPVS 커널 모듈이 +사용 가능한지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는 +iptables 프록시 모드로 다시 실행된다. +{{< /note >}} + +{{< figure src="/images/docs/services-ipvs-overview.svg" title="IPVS 프록시에 대한 서비스 개요 다이어그램" class="diagram-medium" >}} + +## 세션 어피니티 + +이러한 프록시 모델에서, +클라이언트가 쿠버네티스/서비스/파드에 대해 전혀 모르더라도 +서비스의 IP:포트로 향하는 트래픽은 적절한 백엔드로 프록시된다. + +특정 클라이언트의 연결이 매번 동일한 파드로 +전달되도록 하려면, 서비스의 `.spec.sessionAffinity`를 `ClientIP`로 설정하여 +클라이언트의 IP 주소를 기반으로 세션 어피니티를 선택할 수 있다. +(기본값은 `None`) + +### 세션 고정(Session stickiness) 타임아웃 + +서비스의 `.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 적절히 설정하여 +최대 세션 고정 시간을 설정할 수도 있다. +(기본값은 10800으로, 이는 3시간에 해당됨) + +{{< note >}} +윈도우에서는, 서비스의 최대 세션 고정 시간(maximum session sticky time)을 설정하는 것이 지원되지 않는다. +{{< /note >}} + +## 서비스에 IP 주소 할당 + +고정된 목적지로 실제로 라우팅되는 파드 IP 주소와 달리, +서비스 IP는 실제로는 단일 호스트에서 응답하지 않는다. +대신에, kube-proxy는 패킷 처리 로직(예: 리눅스의 iptables)을 사용하여, +필요에 따라 투명하게 리다이렉션되는 _가상_ IP 주소를 정의한다. + +클라이언트가 VIP에 연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다. +환경 변수와 서비스 용 DNS는 +실제로는 서비스의 가상 IP 주소 (및 포트)로 채워진다. + +### 충돌 방지하기 + +쿠버네티스의 주요 철학 중 하나는, +사용자가 잘못한 것이 없는 경우에는 실패할 수 있는 상황에 노출되어서는 안된다는 것이다. +서비스 리소스 설계 시, +다른 사람의 포트 선택과 충돌할 경우에 대비해 자신의 포트 번호를 선택하지 않아도 된다. +만약 그러한 일이 발생한다면 그것은 격리 실패이다. + +서비스에 대한 포트 번호를 사용자가 선택할 수 있도록 하려면, +두 개의 서비스가 충돌하지 않도록 해야 한다. +쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서 +각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다. + +각 서비스가 고유한 IP를 받도록 하기 위해, 각 서비스를 만들기 전에 내부 할당기가 +{{< glossary_tooltip term_id="etcd" >}}에서 +글로벌 할당 맵을 원자적으로(atomically) 업데이트한다. +서비스가 IP 주소 할당을 가져오려면 레지스트리에 맵 오브젝트가 있어야 하는데, +그렇지 않으면 IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다. + +컨트롤 플레인에서, 백그라운드 컨트롤러는 해당 맵을 생성해야 +한다(인-메모리 잠금을 사용하는 이전 버전의 쿠버네티스에서의 마이그레이션 지원을 위해 필요함). +쿠버네티스는 또한 컨트롤러를 사용하여 유효하지 않은 +할당(예: 관리자 개입에 의한)을 체크하고 +더 이상 어떠한 서비스도 사용하지 않는 할당된 IP 주소를 정리한다. + +#### 서비스 가상 IP 주소의 IP 주소 범위 {#service-ip-static-sub-range} + +{{< feature-state for_k8s_version="v1.25" state="beta" >}} + +쿠버네티스는 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 +`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, +여기서 이 공식은 _16 이상 256 이하이며, +그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. + +쿠버네티스는 서비스에 대한 동적 IP 할당 시 상위 대역에서 우선적으로 선택하며, +이는 곧 만약 사용자가 `type: ClusterIP` 서비스에 특정 IP 주소를 할당하고 싶다면 +**하위** 대역에서 골라야 함을 의미한다. +이렇게 함으로써 할당 시 충돌의 위험을 줄일 수 있다. + +만약 `ServiceIPStaticSubrange` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화하면 +쿠버네티스는 `type: ClusterIP` 서비스에 대해 +수동 및 동적 할당 IP 주소를 위한 하나의 공유되는 풀을 사용한다. + +## 트래픽 폴리시 + +`.spec.internalTrafficPolicy` 및 `.spec.externalTrafficPolicy` 필드를 설정하여 +쿠버네티스가 트래픽을 어떻게 정상(healthy, “ready”) 백엔드로 라우팅할지를 제어할 수 있다. + +### 내부 트래픽 폴리시 + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +`spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다. +이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. +필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, +`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. +만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 드롭시킨다. + +### 외부 트래픽 폴리시 + +`spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다. +이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. +필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, +`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. +만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 엔드포인트가 하나도 없는 경우, +kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다. + +### 종료 중인 엔드포인트로 가는 트래픽 + +{{< feature-state for_k8s_version="v1.26" state="beta" >}} + +kube-proxy에 대해 `ProxyTerminatingEndpoints` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고 +트래픽 폴리시가 `Local`이면, +해당 노드의 kube-proxy는 서비스에 대한 엔드포인트를 선택할 때 좀 더 복잡한 알고리즘을 사용한다. +이 기능이 활성화되어 있으면, kube-proxy는 노드가 로컬 엔드포인트를 갖고 있는지, +그리고 모든 로컬 엔드포인트가 '종료 중'으로 표시되어 있는지 여부를 확인한다. +만약 로컬 엔드포인트가 존재하고 **모든** 로컬 엔드포인트가 종료 중이면, +kube-proxy는 종료 중인 해당 엔드포인트로 트래픽을 전달한다. +이외의 경우, kube-proxy는 종료 중이 아닌 엔드포인트로 트래픽을 전달하는 편을 선호한다. + +종료 중인 엔드포인트에 대한 이러한 포워딩 정책 덕분에, `externalTrafficPolicy: Local`을 사용하는 경우에 +`NodePort` 및 `LoadBalancer` 서비스가 연결들을 자비롭게(gracefully) 종료시킬 수 있다. + +디플로이먼트가 롤링 업데이트될 때, 로드밸런서 뒤에 있는 노드가 해당 디플로이먼트의 레플리카를 N개에서 0개 갖도록 변경될 수 있다. +일부 경우에, 외부 로드 밸런서가 헬스 체크 프로브 사이의 기간에 레플리카 0개를 갖는 노드로 트래픽을 전송할 수 있다. +종료 중인 엔드포인트로의 트래픽 라우팅 기능을 통해 +파드를 스케일 다운 중인 노드가 해당 종료 중인 파드로의 트래픽을 자비롭게 수신 및 드레인할 수 있다. +파드 종료가 완료되면, 외부 로드 밸런서는 이미 노드의 헬스 체크가 실패했음을 확인하고 +해당 노드를 백엔드 풀에서 완전히 제거했을 것이다. + +## {{% heading "whatsnext" %}} + +서비스에 대해 더 알아보려면, +[서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/)을 읽어 본다. + +또한, + +* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 읽어 본다. +* 서비스 API에 대한 [API 레퍼런스](/docs/reference/kubernetes-api/service-resources/service-v1/)를 읽어 본다. From 44334fa4a229a1a8950851e8393bf4c0a8b101b1 Mon Sep 17 00:00:00 2001 From: mtardy Date: Tue, 20 Dec 2022 16:02:05 +0100 Subject: [PATCH 15/69] Update CVE feed layouts for new JSON feed format Also add information about last update time on CVE table --- data/i18n/en/en.toml | 10 ++++++++-- layouts/_default/cve-feed.json | 24 +----------------------- layouts/shortcodes/cve-feed.html | 13 +++++++------ 3 files changed, 16 insertions(+), 31 deletions(-) diff --git a/data/i18n/en/en.toml b/data/i18n/en/en.toml index eee6e8661b..d477cb95b8 100644 --- a/data/i18n/en/en.toml +++ b/data/i18n/en/en.toml @@ -67,8 +67,14 @@ other = "Issue Summary" [cve_table] other = "Official Kubernetes CVE List" -[cve_url] -other = "CVE URL" +[cve_table_date_before] +other = "(last updated: " + +[cve_table_date_format] +other = "02 Jan 2006 15:04:05 MST" + +[cve_table_date_after] +other = ")" [deprecation_title] other = "You are viewing documentation for Kubernetes version:" diff --git a/layouts/_default/cve-feed.json b/layouts/_default/cve-feed.json index a185fde22f..3812e9533b 100644 --- a/layouts/_default/cve-feed.json +++ b/layouts/_default/cve-feed.json @@ -1,23 +1 @@ -{ - "version": "https://jsonfeed.org/version/1.1", - "title": "Auto-refreshing Official CVE Feed", - "home_page_url": "https://kubernetes.io", - "feed_url": "https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json", - "description": "Auto-refreshing official CVE feed for Kubernetes repository", - "authors": [ - { - "name": "Kubernetes Community", - "url": "https://www.kubernetes.dev" - } - ], - "items": [ - {{ range $i, $e := getJSON .Site.Params.cveFeedBucket }} - {{ if $i }}, {{ end }} - { - {{ T "cve_json_id" | jsonify }}: {{ .cve_id | jsonify }}, - {{ T "cve_json_url" | jsonify }}: {{ .issue_url | jsonify }}, - {{ T "cve_json_external_url" | jsonify }}: {{ .cve_url | jsonify}}, - {{ T "cve_json_summary" | jsonify }}: {{ replace (.summary | jsonify ) "\\u003e" ">" }} - }{{ end }} - ] -} +{{ getJSON .Site.Params.cveFeedBucket | jsonify }} diff --git a/layouts/shortcodes/cve-feed.html b/layouts/shortcodes/cve-feed.html index 1c04efab7e..7c4aa2d56c 100644 --- a/layouts/shortcodes/cve-feed.html +++ b/layouts/shortcodes/cve-feed.html @@ -1,19 +1,20 @@ - + {{ $feed := getJSON .Site.Params.cveFeedBucket }} + - + - {{ range $issues := getJSON .Site.Params.cveFeedBucket }} + {{ range $feed.items }} - + - + {{ end }} -
{{ T "cve_table" }}{{ T "cve_table" }} {{ T "cve_table_date_before" }}{{ $feed._kubernetes_io.updated_at | time.Format ( T "cve_table_date_format" ) }}{{ T "cve_table_date_after" }}
{{ T "cve_id" }}{{ T "cve_summary"}}{{ T "cve_summary" }} {{ T "cve_issue_url" }}
{{ .cve_id | htmlEscape | safeHTML }}{{ .id | htmlEscape | safeHTML }} {{ .summary | htmlEscape | safeHTML }}#{{ .number }}#{{ ._kubernetes_io.issue_number }}
\ No newline at end of file + From 6f22f71726780f63d5274b077c75ae72b5637955 Mon Sep 17 00:00:00 2001 From: jongwooo Date: Thu, 9 Mar 2023 10:09:12 +0900 Subject: [PATCH 16/69] [ko] Update outdated files in dev-1.26-ko.1 (M197-M200) Signed-off-by: jongwooo --- content/ko/examples/application/deployment-scale.yaml | 2 +- .../ko/examples/application/mysql/mysql-statefulset.yaml | 2 +- content/ko/examples/controllers/daemonset.yaml | 6 ------ .../kind-with-cluster-level-baseline-pod-security.sh | 2 +- 4 files changed, 3 insertions(+), 9 deletions(-) diff --git a/content/ko/examples/application/deployment-scale.yaml b/content/ko/examples/application/deployment-scale.yaml index 01fe96d845..838576375e 100644 --- a/content/ko/examples/application/deployment-scale.yaml +++ b/content/ko/examples/application/deployment-scale.yaml @@ -14,6 +14,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.14.2 + image: nginx:1.16.1 ports: - containerPort: 80 diff --git a/content/ko/examples/application/mysql/mysql-statefulset.yaml b/content/ko/examples/application/mysql/mysql-statefulset.yaml index 8bed6ee51d..a9970b37b3 100644 --- a/content/ko/examples/application/mysql/mysql-statefulset.yaml +++ b/content/ko/examples/application/mysql/mysql-statefulset.yaml @@ -24,7 +24,7 @@ spec: - | set -ex # 파드의 원래 인덱스에서 mysql server-id를 생성. - [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + [[ $HOSTNAME =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf.d/server-id.cnf # 예약된 server-id=0 값을 피하기 위해 오프셋 추가. diff --git a/content/ko/examples/controllers/daemonset.yaml b/content/ko/examples/controllers/daemonset.yaml index c17ebfe5c5..bb33773ff1 100644 --- a/content/ko/examples/controllers/daemonset.yaml +++ b/content/ko/examples/controllers/daemonset.yaml @@ -35,14 +35,8 @@ spec: volumeMounts: - name: varlog mountPath: /var/log - - name: varlibdockercontainers - mountPath: /var/lib/docker/containers - readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - - name: varlibdockercontainers - hostPath: - path: /var/lib/docker/containers diff --git a/content/ko/examples/security/kind-with-cluster-level-baseline-pod-security.sh b/content/ko/examples/security/kind-with-cluster-level-baseline-pod-security.sh index 3a0e2acf48..b8dea7589b 100644 --- a/content/ko/examples/security/kind-with-cluster-level-baseline-pod-security.sh +++ b/content/ko/examples/security/kind-with-cluster-level-baseline-pod-security.sh @@ -6,7 +6,7 @@ kind: AdmissionConfiguration plugins: - name: PodSecurity configuration: - apiVersion: pod-security.admission.config.k8s.io/v1beta1 + apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" From b710cfc7cd5eea07f7ff488ffea165eb40118d3c Mon Sep 17 00:00:00 2001 From: jongwooo Date: Mon, 6 Mar 2023 18:05:08 +0900 Subject: [PATCH 17/69] [ko] Update outdated files in dev-1.26-ko.1 (M174-M188) Signed-off-by: jongwooo --- content/ko/docs/tutorials/_index.md | 1 + content/ko/docs/tutorials/hello-minikube.md | 2 +- content/ko/docs/tutorials/kubernetes-basics/_index.html | 2 -- .../create-cluster/cluster-interactive.html | 2 -- .../kubernetes-basics/create-cluster/cluster-intro.html | 2 -- .../kubernetes-basics/deploy-app/deploy-interactive.html | 2 -- .../kubernetes-basics/deploy-app/deploy-intro.html | 2 -- .../kubernetes-basics/explore/explore-interactive.html | 2 -- .../tutorials/kubernetes-basics/explore/explore-intro.html | 3 --- .../kubernetes-basics/expose/expose-interactive.html | 2 -- .../tutorials/kubernetes-basics/expose/expose-intro.html | 6 ++---- .../kubernetes-basics/scale/scale-interactive.html | 2 -- .../docs/tutorials/kubernetes-basics/scale/scale-intro.html | 2 -- .../kubernetes-basics/update/update-interactive.html | 2 -- .../tutorials/kubernetes-basics/update/update-intro.html | 3 --- 15 files changed, 4 insertions(+), 31 deletions(-) diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 4b708f68fe..a96a42f927 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -49,6 +49,7 @@ content_type: concept ## 서비스 +* [서비스들로 애플리케이션에 접속하기](/docs/tutorials/services/connect-applications-service/) * [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/) ## 보안 diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index fc360d1d06..269ad04050 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -94,7 +94,7 @@ minikube dashboard --url 파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다. ```shell - kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4 + kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080 ``` 2. 디플로이먼트 보기 diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index f1ab593581..44569c6974 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -15,8 +15,6 @@ card: - -

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 b635f4f6f2..ba3edcf62d 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 @@ -9,8 +9,6 @@ weight: 20 - - {{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 415b79362b..8336bd2589 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -9,8 +9,6 @@ weight: 10 - -
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 c67f9ad124..1772c973e1 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 @@ -9,8 +9,6 @@ weight: 20 - - {{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 162121de29..280c2a17a5 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -9,8 +9,6 @@ weight: 10 - -
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 6e710c8099..5f9079e36d 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -9,8 +9,6 @@ weight: 20 - - {{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html index c09d8c014e..1c013443c5 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -9,9 +9,6 @@ weight: 10 - - -
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 cf6abdccd9..f084fcd8f2 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -9,8 +9,6 @@ weight: 20 - - {{< katacoda-tutorial >}}
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 8f56b5ef70..58379c932e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -9,8 +9,6 @@ weight: 10 - -
@@ -28,7 +26,7 @@ weight: 10

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

-

쿠버네티스 파드들 은 언젠가는 죽게된다. 실제 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리카셋(ReplicaSet)은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

+

쿠버네티스 파드들 은 언젠가는 죽게된다. 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리카셋(ReplicaSet)은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.

쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML (보다 선호하는) 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 LabelSelector에 의해 결정된다 (여러분이 왜 스펙에 selector가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).

@@ -39,7 +37,7 @@ weight: 10
  • LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
  • ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, foo.bar.example.com)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.
    • -

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

    +

    다른 서비스 타입들에 대한 추가 정보는 소스 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 ace5f93f17..ef199df2c6 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -9,8 +9,6 @@ weight: 20 - - {{< katacoda-tutorial >}}
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index b494b175dd..df35a3513c 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -9,8 +9,6 @@ weight: 10 - -
    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 b644355c4e..82e9c3b215 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -9,8 +9,6 @@ weight: 20 - - {{< katacoda-tutorial >}}
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html index 8ae737bde5..36b055a362 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -9,9 +9,6 @@ weight: 10 - - -
    From ea401f2bf340f14731541ce65636a803f8289fd3 Mon Sep 17 00:00:00 2001 From: jongwooo Date: Mon, 20 Feb 2023 00:31:37 +0900 Subject: [PATCH 18/69] [ko] Update outdated files in dev-1.26-ko.1 (M134-M142) Signed-off-by: jongwooo --- content/ko/docs/setup/_index.md | 2 +- .../ko/docs/setup/best-practices/certificates.md | 4 ++-- .../ko/docs/setup/best-practices/cluster-large.md | 2 +- .../enforcing-pod-security-standards.md | 6 +++--- .../ko/docs/setup/production-environment/_index.md | 2 +- .../setup/production-environment/tools/kops.md | 14 +++++++------- .../tools/kubeadm/install-kubeadm.md | 8 ++++++-- .../production-environment/tools/kubespray.md | 11 ++++++----- .../production-environment/turnkey-solutions.md | 2 +- 9 files changed, 28 insertions(+), 23 deletions(-) diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index d0970b1bdc..54846ea580 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -27,7 +27,7 @@ card: [쿠버네티스를 다운로드](/releases/download/)하여 로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다. -`kube-apiserver`나 `kube-proxy`와 같은 몇몇 [쿠버네티스 컴포넌트](/releases/download/)들은 +{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}나 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}와 같은 몇몇 [쿠버네티스 컴포넌트](/releases/download/)들은 클러스터 내에서 [컨테이너 이미지](/releases/download/#container-images)를 통해 배포할 수 있다. 쿠버네티스 컴포넌트들은 가급적 컨테이너 이미지로 실행하는 것을 **추천**하며, diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 9dd69d391c..33400f581a 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -3,7 +3,7 @@ title: PKI 인증서 및 요구 사항 # reviewers: # - sig-cluster-lifecycle content_type: concept -weight: 40 +weight: 50 --- @@ -208,4 +208,4 @@ KUBECONFIG= kubectl config use-context default-system /etc/kubernetes/kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf -``` \ No newline at end of file +``` diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index ea6827e264..c1795990b8 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -3,7 +3,7 @@ # - davidopp # - lavalamp title: 대형 클러스터에 대한 고려 사항 -weight: 20 +weight: 10 --- 클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는 diff --git a/content/ko/docs/setup/best-practices/enforcing-pod-security-standards.md b/content/ko/docs/setup/best-practices/enforcing-pod-security-standards.md index fd86f3a129..1ce3d42f24 100644 --- a/content/ko/docs/setup/best-practices/enforcing-pod-security-standards.md +++ b/content/ko/docs/setup/best-practices/enforcing-pod-security-standards.md @@ -15,7 +15,7 @@ weight: 40 ## 내장된 파드 시큐리티 어드미션 컨트롤러 사용 -{{< feature-state for_k8s_version="v1.23" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} [파드 시큐리티 어드미션 컨트롤러(Pod Security Admission Controller)](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)는 더 이상 사용되지 않는 파드시큐리티폴리시(PodSecurityPolicy)를 대체한다. @@ -28,7 +28,7 @@ weight: 40 레이블이 없는 네임스페이스는 아직 평가되지 않았음을 표시해야 한다. 모든 네임스페이스의 모든 워크로드에 동일한 보안 요구 사항이 있는 시나리오에서, -파드 시큐리티 레이블을 대량으로 적용할 수 있는 방법을 보여주는 [예시](/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)를 +파드 시큐리티 레이블을 대량으로 적용할 수 있는 방법을 보여주는 [예시](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces)를 제공한다. ### 최소 권한 원칙 수용 @@ -77,4 +77,4 @@ weight: 40 _내장_ 솔루션(예: 파드 시큐리티 어드미션 컨트롤러)과 타사 도구를 사용할지 여부는 전적으로 사용자의 상황에 달려 있다. 솔루션을 평가할 때 공급망의 신뢰가 중요하다. 궁극적으로 앞서 언급한 접근 방식 중 -하나를 사용하는 것이 아무것도 하지 않는 것보다 낫다. \ No newline at end of file +하나를 사용하는 것이 아무것도 하지 않는 것보다 낫다. diff --git a/content/ko/docs/setup/production-environment/_index.md b/content/ko/docs/setup/production-environment/_index.md index efa6ed4e78..e62c89c09b 100644 --- a/content/ko/docs/setup/production-environment/_index.md +++ b/content/ko/docs/setup/production-environment/_index.md @@ -117,7 +117,7 @@ no_list: true 또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. etcd는 클러스터 구성 데이터를 저장하므로 필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다. - [etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다. + [etcd FAQ](https://etcd.io/docs/v3.5/faq/)에서 etcd 구성 및 사용 상세를 확인한다. [쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 [kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 상세 사항을 확인한다. diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index d4ec7f47de..3eb395d26c 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -1,5 +1,5 @@ --- -title: Kops로 쿠버네티스 설치하기 +title: kOps로 쿠버네티스 설치하기 content_type: task weight: 20 --- @@ -7,14 +7,14 @@ weight: 20 이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다. -[`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다. +[`kOps`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다. -kops는 자동화된 프로비저닝 시스템인데, +kOps는 자동화된 프로비저닝 시스템인데, * 완전 자동화된 설치 * DNS를 통해 클러스터들의 신원 확인 * 자체 복구: 모든 자원이 Auto-Scaling Groups에서 실행 -* 다양한 OS 지원(Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md) 보기 +* 다양한 OS 지원(Amazon Linux, Debian, Flatcar, RHEL, Rocky and Ubuntu) - [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md) 보기 * 고가용성 지원 - [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md) 보기 * 직접 프로비저닝 하거나 또는 할 수 있도록 terraform 매니페스트를 생성 - [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) 보기 @@ -232,6 +232,6 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의 * 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/)에 대해 더 알아보기. -* 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다. -* 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) -* 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues) +* 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kOps` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다. +* 슬랙(Slack)에서 `kOps` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) +* 문제를 해결하거나 이슈를 제기하여 `kOps` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues) 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 448b25b0ff..596b10b8b8 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 @@ -156,13 +156,13 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으 2. 구글 클라우드의 공개 사이닝 키를 다운로드 한다. ```shell - sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` 3. 쿠버네티스 `apt` 리포지터리를 추가한다. ```shell - echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` 4. `apt` 패키지 색인을 업데이트하고, kubelet, kubeadm, kubectl을 설치하고 해당 버전을 고정한다. @@ -172,6 +172,10 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으 sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` +{{< note >}} +Debian 12 및 Ubuntu 22.04 이전 릴리스에서는 `/etc/apt/keyring`이 기본적으로 존재하지 않는다. +필요한 경우 이 디렉토리를 생성하여, 누구나 읽을 수 있지만 관리자만 쓸 수 있도록 만들 수 있다. +{{< /note >}} {{% /tab %}} {{% tab name="레드햇 기반 배포판" %}} diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index 5f6003c504..52e52b83cd 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -17,13 +17,14 @@ Kubespray 지원 사항 - Flatcar Container Linux by Kinvolk - Debian Bullseye, Buster, Jessie, Stretch - Ubuntu 16.04, 18.04, 20.04, 22.04 - - CentOS/RHEL 7, 8 - - Fedora 34, 35 + - CentOS/RHEL 7, 8, 9 + - Fedora 35, 36 - Fedora CoreOS - openSUSE Leap 15.x/Tumbleweed - - Oracle Linux 7, 8 - - Alma Linux 8 - - Rocky Linux 8 + - Oracle Linux 7, 8, 9 + - Alma Linux 8, 9 + - Rocky Linux 8, 9 + - Kylin Linux Advanced Server V10 - Amazon Linux 2 * 지속적인 통합 (CI) 테스트 diff --git a/content/ko/docs/setup/production-environment/turnkey-solutions.md b/content/ko/docs/setup/production-environment/turnkey-solutions.md index 2feb5de30a..af45271507 100644 --- a/content/ko/docs/setup/production-environment/turnkey-solutions.md +++ b/content/ko/docs/setup/production-environment/turnkey-solutions.md @@ -1,7 +1,7 @@ --- title: 턴키 클라우드 솔루션 content_type: concept -weight: 30 +weight: 40 --- From 2b8112d451bd78f4630a68c5c17e3954fbdcc8b8 Mon Sep 17 00:00:00 2001 From: YujinChoi Date: Mon, 27 Feb 2023 23:08:55 +0900 Subject: [PATCH 19/69] [ko] Update outdated files in `dev-1.26-ko.1` (M59) --- .../services-networking/dns-pod-service.md | 140 ++++++++++-------- 1 file changed, 79 insertions(+), 61 deletions(-) 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 267f8a1e3b..35a72f32ad 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -1,10 +1,14 @@ --- # reviewers: -# - davidopp +# - jbelamaric +# - bowei # - thockin title: 서비스 및 파드용 DNS content_type: concept -weight: 20 +weight: 80 +description: >- + 워크로드는 DNS를 사용하여 클러스터 내의 서비스들을 발견할 수 있다; + 이 페이지는 이것이 어떻게 동작하는지를 설명한다. --- @@ -13,13 +17,11 @@ weight: 20 -## 소개 +쿠버네티스는 DNS를 설정 하기 위해 사용되는 +파드와 서비스에 대한 정보를 발행한다. Kubelet은 실행 중인 컨테이너가 +IP가 아닌 이름으로 서비스를 검색할 수 있도록 파드의 DNS를 설정한다. -쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, -개별 컨테이너들이 DNS 네임을 해석할 때 -DNS 서비스의 IP를 사용하도록 kubelet을 구성한다. - -클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. +클러스터 내의 서비스에는 DNS 네임이 할당된다. 기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 클러스터의 기본 도메인을 포함한다. @@ -49,8 +51,8 @@ search .svc.cluster.local svc.cluster.local cluster.local options ndots:5 ``` -요약하면, _test_ 네임스페이스에 있는 파드는 `data.prod` 또는 -`data.prod.svc.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다. +요약하면, _test_ 네임스페이스에 있는 파드는, `prod` 네임스페이스에 있는 `data` 파드를 가리키는 도메인 이름인 +`data.prod` 또는 `data.prod.svc.cluster.local` 을 성공적으로 해석할 수 있다. ### DNS 레코드 @@ -69,29 +71,28 @@ options ndots:5 ### A/AAAA 레코드 -"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라 +"노멀"(헤드리스가 아닌) 서비스는 서비스의 IP family 혹은 IP families 에 따라 `my-svc.my-namespace.svc.cluster-domain.example` 형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. -"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. -노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) +(클러스터 IP가 없는) 또한 `my-svc.my-namespace.svc.cluster-domain.example` +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 노멀 서비스와는 달리 +이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. 클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. ### SRV 레코드 -SRV 레코드는 노멀 서비스 또는 -[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 -속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. -`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. -정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. +SRV 레코드는 노멀 서비스 또는 헤드리스 서비스에 속하는 네임드 포트를 위해 만들어졌다. +각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 갖는다. +`_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. +정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다: `my-svc.my-namespace.svc.cluster-domain.example`. 헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 포트 번호와 도메인 이름을 포함한다. -`auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. +`hostname.my-svc.my-namespace.svc.cluster-domain.example`. ## 파드 @@ -112,17 +113,25 @@ SRV 레코드는 노멀 서비스 또는 ### 파드의 hostname 및 subdomain 필드 -파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다. +파드가 생성되면 hostname(파드 내부에서 확인된 것 처럼)은 +해당 파드의 `metadata.name` 값이 된다. -파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. -이 필드는 파드의 호스트네임을 지정할 수 있다. -`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. -예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다. +파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. 이 필드는 +다른 호스트네임을 지정할 수 있다. `hostname` 필드가 지정되면, 파드의 이름보다 +파드의 호스트네임이 우선시된다.(역시 파드 내에서 확인된 것 처럼) 예를 들어, +`spec.hostname` 필드가 "`my-host`"로 설정된 파드는 +호스트네임이 "`my-host`"로 설정된다. -또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. -예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, -`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. -"`foo.bar.my-namespace.svc.cluster-domain.example`". +또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 파드가 네임스페이스의 +서브 그룹의 일부임을 나타낼 수 있다. 예를 들어 "`my-namespace`" 네임스페이스에서, `spec.hostname` 필드가 +"`foo`"로 설정되고, `spec.subdomain` 필드가 "`bar`"로 설정된 파드는 +전체 주소 도메인 네임(FQDN)을 가지게 된다. +"`foo.bar.my-namespace.svc.cluster-domain.example`" (다시 한 번, 파드 내부 에서 +확인된 것 처럼). + +파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 +헤드리스 서비스가 있다면, 클러스터의 DNS 서버는 +파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. 예시: @@ -130,15 +139,14 @@ SRV 레코드는 노멀 서비스 또는 apiVersion: v1 kind: Service metadata: - name: default-subdomain + name: busybox-subdomain spec: selector: name: busybox clusterIP: None ports: - - name: foo # 사실 포트는 필요하지 않다. + - name: foo # 단일 포트 서비스에 이름은 필수사항이 아니다. port: 1234 - targetPort: 1234 --- apiVersion: v1 kind: Pod @@ -148,7 +156,7 @@ metadata: name: busybox spec: hostname: busybox-1 - subdomain: default-subdomain + subdomain: busy-subdomain containers: - image: busybox:1.28 command: @@ -164,7 +172,7 @@ metadata: name: busybox spec: hostname: busybox-2 - subdomain: default-subdomain + subdomain: busy-subdomain containers: - image: busybox:1.28 command: @@ -173,24 +181,20 @@ spec: name: busybox ``` -파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, -클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. -예를 들어 호스트네임이 "`busybox-1`"이고, -서브도메인이 "`default-subdomain`"이고, -같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, -파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. -"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". -DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. -"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. +위의 주어진 서비스 "`busybox-subdomain`"과 `spec.subdomain`이 +"`busybox-subdomain`"으로 설정된 파드에서, 첫번째 파드는 다음과 같은 자기 자신의 FQDN을 확인하게 된다. +"`busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example`". DNS는 +위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. "`busybox1`"와 +"`busybox2`" 파드 모두 각 파드의 주소 레코드를 갖게 된다. -엔드포인트 오브젝트는 `hostname` 필드를 -임의의 엔드포인트 IP 주소로 지정할 수 있다. +{{}}는 +임의의 엔드포인트 주소에 대해 해당 IP와 함께 DNS 호스트 네임을 지정할 수 있다. {{< note >}} -A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 +A 와 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. `hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 -A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`) +A 또는 AAAA 레코드만 생성할 수 있다. (`busybox-subdomain.my-namespace.svc.cluster-domain.example`) 또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다. {{< /note >}} @@ -198,7 +202,11 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac {{< 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을 반환한다. +파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, +해당 호스트네임은 짧은 호스트네임이다. +예를 들어, 전체 주소 도메인 이름이 `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, +기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 +`hostname --fqdn` 명령은 FQDN을 반환한다. 파드 명세에서 `setHostnameAsFQDN: true` 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, `hostname` 과 `hostname --fqdn` 은 모두 파드의 FQDN을 반환한다. @@ -214,18 +222,20 @@ DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. 이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다. -- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. - 자세한 내용은 - [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 +- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 + 네임 해석 설정(the name resolution configuration)을 상속받는다. + 자세한 내용은 [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 확인할 수 있다. - "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 - 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. + 일치하지 않는 DNS 쿼리는 DNS 서버에 의해 업스트림 네임서버로 전달된다. 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 - "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. + "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. 그렇지 않으면, + hostNetwork와 `"ClusterFirst"`로 실행되고 있는 파드는 + `"Default"` 정책으로 동작한다. - 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다. - "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. @@ -313,16 +323,24 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom options ndots:5 ``` -#### 확장된 DNS 환경 설정 +## DNS 탐색 도메인 리스트 제한 -{{< feature-state for_k8s_version="1.22" state="alpha" >}} +{{< feature-state for_k8s_version="1.26" state="beta" >}} -쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과 -최대 256자의 탐색 도메인 목록을 허용한다. +쿠버네티스는 탐색 도메인 리스트가 32개를 넘거나 모든 탐색 도메인의 길이가 2048자를 +초과할 때까지 DNS Config에 자체적인 제한을 하지 않는다. +이 제한은 노드의 resolver 설정 파일, 파드의 DNS Config, +그리고 합쳐진 DNS Config에 각각 적용된다. -kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면, -쿠버네티스는 최대 32개의 탐색 도메인과 -최대 2048자의 탐색 도메인 목록을 허용한다. +{{< note >}} +이전 버전의 일부 컨테이너 런타임은 DNS 탐색 도메인 수에 대해 +자체적인 제한을 가지고 있을 수 있다. 컨테이너 런타임 환경에 따라 +많은 수의 DNS 검색 도메인을 갖는 파드는 +pending 상태로 고착될 수 있다. + +containerd v1.5.5 혹은 그 이전 그리고 CRI-O v1.21 혹은 그 이전에서 이러한 문제가 +발생하는 것으로 알려졌다. +{{< /note >}} ## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows} From 4d9dc64f95e42c7b96f1ca03092bbf813c5a8a51 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Tue, 10 Jan 2023 12:14:58 +0900 Subject: [PATCH 20/69] Update outdated files in dev-1.26-ko.1 (M98-M108) --- content/ko/docs/contribute/advanced.md | 2 +- content/ko/docs/contribute/analytics.md | 2 +- .../contribute/generate-ref-docs/_index.md | 2 +- .../generate-ref-docs/quickstart.md | 6 ++- .../participate/roles-and-responsibilities.md | 4 +- .../docs/contribute/review/for-approvers.md | 8 ++-- .../docs/contribute/review/reviewing-prs.md | 44 +++++++++++++++++-- .../docs/contribute/style/write-new-topic.md | 4 +- content/ko/docs/reference/_index.md | 5 ++- .../reference/access-authn-authz/_index.md | 2 +- .../access-authn-authz/kubelet-authn-authz.md | 1 + 11 files changed, 60 insertions(+), 20 deletions(-) diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 047dfe37a8..6d2fcc4d32 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -2,7 +2,7 @@ title: 고급 기여 slug: advanced content_type: concept -weight: 98 +weight: 100 --- diff --git a/content/ko/docs/contribute/analytics.md b/content/ko/docs/contribute/analytics.md index d96d1ed576..d4e83ab5a9 100644 --- a/content/ko/docs/contribute/analytics.md +++ b/content/ko/docs/contribute/analytics.md @@ -1,7 +1,7 @@ --- title: 사이트 분석 보기 content_type: concept -weight: 100 +weight: 120 card: name: contribute weight: 100 diff --git a/content/ko/docs/contribute/generate-ref-docs/_index.md b/content/ko/docs/contribute/generate-ref-docs/_index.md index ad9d221f15..e08c387c83 100644 --- a/content/ko/docs/contribute/generate-ref-docs/_index.md +++ b/content/ko/docs/contribute/generate-ref-docs/_index.md @@ -1,5 +1,5 @@ --- -title: 레퍼런스 문서 개요 +title: 레퍼런스 문서 갱신하기 main_menu: true weight: 80 --- diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md index 775c7ed77a..24091ce8e6 100644 --- a/content/ko/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/ko/docs/contribute/generate-ref-docs/quickstart.md @@ -1,7 +1,9 @@ --- -title: 퀵스타트 가이드 +title: 레퍼런스 문서 퀵스타트 가이드 +linkTitle: Quickstart content_type: task -weight: 40 +weight: 10 +hide_summary: true --- diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index f816a12191..23201553f9 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -102,7 +102,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D ## 리뷰어 리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, -여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 +PR 작성자는 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 팀의 멤버이다. @@ -192,7 +192,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리 {{< /warning >}} - 제안된 변경이 - [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. + [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/)에 적합한지 확인한다. 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 3ded883231..1e49d02cf0 100644 --- a/content/ko/docs/contribute/review/for-approvers.md +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -81,14 +81,14 @@ Prow 명령 | 역할 제한 | 설명 :------------|:------------------|:----------- `/lgtm` | 조직 멤버 | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다. `/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다. -`/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다. -`/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다. +`/assign` | 누구나 | PR을 리뷰하거나 승인할 사람을 지정한다. +`/close` | 조직 멤버 | 이슈 또는 PR을 닫는다. `/hold` | 누구나 | 자동으로 병합할 수 없음을 나타내는 `do-not-merge/hold` 레이블을 추가한다. `/hold cancel` | 누구나 | `do-not-merge/hold` 레이블을 제거한다. {{< /table >}} -PR에서 사용할 수 있는 명령의 전체 목록을 보려면 -[Prow 명령 레퍼런스](https://prow.k8s.io/command-help)를 참고한다. +PR에서 사용할 수 있는 명령어들을 보려면 +[Prow 명령 레퍼런스](https://prow.k8s.io/command-help?repo=kubernetes%2Fwebsite)를 참고한다. ## 이슈 심사와 분류 diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index dbd08e60ed..58652b72a7 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -105,10 +105,18 @@ class third,fourth white 1. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다. 1. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서 - 리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!), - PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는 + 리뷰에 대한 요약을 추가한다(기여자에게 긍정적인 의견을 남겨주기 바란다!). 항상 **Comment** 를 선택해야 한다. + - 리뷰를 완료할 때, "Request changes" 버튼을 누르지 않는다. + 만약 몇몇 변경사항들이 반영되기 전에 PR이 병합되는 것을 막고 싶다면, + "/hold" 명령어를 사용한다. + 왜 "/hold"를 사용하는지 언급해줘야 하며, 어떤 경우에 홀드가 제거되는지에 + 대해서 명세해주는 것은 기여자에게 도움이 된다. + + - 리뷰를 완료할 때, "Approve" 버튼을 누르지 않는다. + 대부분의 경우 "/approve" 명령어를 대신 사용한다. + ## 리뷰 체크리스트 리뷰할 때, 다음을 시작점으로 사용한다. @@ -116,6 +124,18 @@ class third,fourth white ### 언어와 문법 - 언어나 문법에 명백한 오류가 있는가? 무언가를 표현하는 더 좋은 방법이 있는가? + - 기여자가 변경한 부분의 언어와 문법에 집중한다. + 기여자가 문서 전체를 갱신하는 것을 목표로 하지 않는 한, + 해당 문서의 모든 이슈들을 해결할 의무는 없다. + - PR이 기존의 문서를 갱신하는 경우, 갱신된 부분을 검토하는데 집중한다. + 변경된 내용이 기술적으로, 그리고 문서적으로 정확한지 + 검토한다. + 기여자가 해결하려는 문제와 직접적으로 관련 있지는 않은 문제들을 발견할 경우, + 개별적인 이슈로써 처리한다 + (그 전에 해당 문제가 이슈화 되어있는지 확인한다). + - 문서의 경로를 _이동_한 PR이 있는지 주의한다. + 기여자가 문서의 이름을 변경하거나 두개 이상의 문서들을 합치는 경우, 우리(쿠버네티스 SIG Docs)는 + 이동된 문서에서 발견할 수 있는 모든 문법이나 철자를 수정하도록 요청하지는 않는다. - 더 간단한 단어로 대체될 수 있는 복잡하거나 오래된 단어가 있는가? - 비 차별적 대안으로 대체될 수 있는 단어, 용어 또는 문구가 있는가? - 단어 선택과 대소문자는 [스타일 가이드](/docs/contribute/style/style-guide/)를 따르는가? @@ -145,5 +165,21 @@ class third,fourth white ### 기타 -오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. -이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. +- [사소한 내용만을 가지고 기여](https://www.kubernetes.dev/docs/guide/pull-requests/#trivial-edits)하는 것에 주의한다; + 사소한 수정으로 간주할 수 있는 수정 요청을 발견한다면, 해당 정책을 알려주는 것이 바람직하다 + (실질적인 개선 사항이라면 수용 가능함). +- 공백을 수정하는 기여자들로 하여금, + PR의 첫번째 커밋에서 공백을 수정한 뒤 다른 변경 사항들을 추가하도록 권장한다. + 이는 검토와 병합 과정을 더욱 쉽게 한다. + 특히 대량으로 공백을 정리하는 하나의 커밋에서 발생하는 사소한 변경사항들에 주의한다. + (만약 이를 확인한 경우, 기여자에게 수정을 권장하도록 한다.) + +리뷰어로써, PR에서 공백 문제나 오타 등 크게 중요하지 않은 사소한 이슈들을 발견하는 경우, +리뷰 앞에 `nit:`을 붙인다. +이렇게 함으로써 기여자가 해당 피드백이 크게 중요하지 않다는 것을 알 수 있다. + +nit으로 표시된 피드백을 제외하고 모든 이슈들을 해결한 PR은 병합할 수 있다. +이러한 경우, 아직 해결되지 않는 nit 사항들에 대하여 새롭게 이슈를 여는 것을 권장한다. +또한 새로운 이슈를 [Good First Issue](https://www.kubernetes.dev/docs/guide/help-wanted/#good-first-issue)]로써 +표시할 수 있는지에 대해 고려해본다. +가능한 경우, 이것은 새로운 기여자에게 좋은 소스가 된다. diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 21529e0ce8..ec955111db 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -1,7 +1,7 @@ --- title: 새로운 주제의 문서 작성 content_type: task -weight: 20 +weight: 70 --- @@ -100,7 +100,7 @@ YAML 블록이다. 여기 예시가 있다. - `kubectl get deploy mydeployment -o json | jq '.status'`와 같은 명령어의 출력을 보여주는 코드. - 시도해보기에는 적절하지 않은 코드. 예를 들어 - 특정 [FlexVolume](/ko/docs/concepts/storage/volumes#flexvolume) 구현에 따라 + 특정 [FlexVolume](/ko/docs/concepts/storage/volumes#flexvolume-deprecated) 구현에 따라 파드를 만들기 위해 YAML 파일을 포함할 수 있다. - 더 큰 파일의 일부분을 강조하기 위한 불완전한 예제 코드. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 0ced9fc52f..3eb5b1fd7a 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -82,8 +82,9 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) * [kubelet 자격증명 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) * [kubelet 자격증명 제공자 (v1beta1)](/docs/reference/config-api/kubelet-credentialprovider.v1beta1/) -* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및 - [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/), + [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) and + [kube-scheduler 환경설정 (v1)](/docs/reference/config-api/kube-scheduler-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/) * [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및 diff --git a/content/ko/docs/reference/access-authn-authz/_index.md b/content/ko/docs/reference/access-authn-authz/_index.md index fc2faebbb6..c58a72fecb 100644 --- a/content/ko/docs/reference/access-authn-authz/_index.md +++ b/content/ko/docs/reference/access-authn-authz/_index.md @@ -1,6 +1,6 @@ --- title: API 접근 제어 -weight: 15 +weight: 30 no_list: true --- diff --git a/content/ko/docs/reference/access-authn-authz/kubelet-authn-authz.md b/content/ko/docs/reference/access-authn-authz/kubelet-authn-authz.md index 2ce711f69d..6cbf766cb3 100644 --- a/content/ko/docs/reference/access-authn-authz/kubelet-authn-authz.md +++ b/content/ko/docs/reference/access-authn-authz/kubelet-authn-authz.md @@ -2,6 +2,7 @@ # reviewers: # - liggitt title: Kubelet 인증/인가 +weight: 110 --- From bbd772cc0e38a21df63faab25b9599730a005a9a Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Sat, 31 Dec 2022 17:16:38 +0900 Subject: [PATCH 21/69] Update outdated files in dev-1.26-ko.1 (M83-M97) --- content/ko/docs/concepts/workloads/_index.md | 2 +- .../workloads/controllers/cron-jobs.md | 9 +- .../workloads/controllers/daemonset.md | 3 +- .../workloads/controllers/deployment.md | 6 +- .../concepts/workloads/controllers/job.md | 121 ++++++++++-------- .../workloads/controllers/replicaset.md | 7 + .../controllers/replicationcontroller.md | 10 +- .../workloads/controllers/statefulset.md | 24 +++- .../ko/docs/concepts/workloads/pods/_index.md | 8 +- .../concepts/workloads/pods/disruptions.md | 10 +- .../concepts/workloads/pods/downward-api.md | 1 + .../workloads/pods/ephemeral-containers.md | 4 + .../workloads/pods/init-containers.md | 4 +- .../concepts/workloads/pods/pod-lifecycle.md | 30 ++++- .../workloads/pods/user-namespaces.md | 4 +- 15 files changed, 148 insertions(+), 95 deletions(-) diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index 09caa7c622..3440a4f779 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -1,6 +1,6 @@ --- title: "워크로드" -weight: 50 +weight: 55 description: > 쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화 no_list: true diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 4979858b41..7add6ca1ef 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -92,6 +92,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다. ## 타임 존 + 크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다. {{< feature-state for_k8s_version="v1.25" state="beta" >}} @@ -101,7 +102,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우, 클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다). -이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 이름으로 지정할 수 있다. +이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)으로 지정할 수 있다. 예를 들어, `spec.timeZone: "Etc/UTC"`와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다. Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다. @@ -123,13 +124,13 @@ Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. -```` +``` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. -```` +``` 중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다. -크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. +크론잡은 정해진 시간에 생성되는데 실패하면 누락(missed)된 것으로 집계된다. 예를 들어 `concurrencyPolicy`가 `Forbid` 로 설정되어 있고 이전 크론잡이 여전히 실행 중인 상태라면, 크론잡은 일정에 따라 시도되었다가 생성을 실패하고 누락된 것으로 집계될 것이다. 즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, `startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 3e42689846..cac2de59b1 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -203,8 +203,7 @@ nodeAffinity: - 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다. - 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`). - 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 - 데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다 - (예: 도커에서 직접적으로 시작). + 데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다. ### 베어(Bare) 파드 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 385fa7269e..33b31dd89f 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -44,9 +44,9 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id= 이 예시에 대한 설명은 다음과 같다. -* `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다. -* `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. -* `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. +* `.metadata.name` 필드에 따라, `nginx-deployment` 이름을 가진 디플로이먼트가 생성된다. +* `.spec.replicas` 필드에 따라, 디플로이먼트는 3개의 레플리카 파드를 생성하는 레플리카셋을 생성한다. +* `.spec.selector` 필드는, 생성된 레플리카셋이 관리할 파드를 찾아내는 방법을 정의한다. 이 사례에서는 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. 그러나 파드 템플릿 자체의 규칙이 만족되는 한, 보다 정교한 선택 규칙의 적용이 가능하다. diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 25a5926f4d..794a0cb2c4 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -1,5 +1,6 @@ --- # reviewers: +# - alculquicondor # - erictune # - soltysh title: 잡 @@ -260,11 +261,12 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 - `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` 환경 변수. + - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). + 인덱스된(Indexed) 잡과 + {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 있다면, 잡에 속한 파드는 + DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 호스트네임을 사용할 수 있다. + 이를 어떻게 설정하는지에 대해 궁금하다면, [파드 간 통신을 위한 잡](/docs/tasks/job/job-with-pod-to-pod-communication/)를 확인한다. + - 컨테이너화된 태스크의 경우, 환경 변수 `JOB_COMPLETION_INDEX`에 있다. 각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로 간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은 @@ -289,6 +291,10 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 한다는 점이다. 특히, 이전 실행으로 인한 임시파일, 잠금, 불완전한 출력 그리고 이와 유사한 것들을 처리해야 한다. +기본적으로 파드의 실패는 `.spec.backoffLimit` 제한값으로 계산되며, +자세한 내용은 [파드 백오프(backoff) 실패 정책](#파드-백오프-backoff-실패-정책)을 확인한다. 그러나, +잡의 [파드 실패 정책](#pod-failure-policy)을 설정하여 파드의 실패 수준을 조절하여 사용할 수도 있다. + `.spec.parallelism = 1`, `.spec.completions = 1` 그리고 `.spec.template.spec.restartPolicy = "Never"` 를 지정하더라도 같은 프로그램을 두 번 시작하는 경우가 있다는 점을 참고한다. @@ -296,6 +302,19 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 `.spec.parallelism` 그리고 `.spec.completions` 를 모두 1보다 크게 지정한다면 한번에 여러 개의 파드가 실행될 수 있다. 따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다. +만약 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)인 +`PodDisruptionConditions`와 `JobPodFailurePolicy`가 모두 활성화되어 있고, +`.spec.podFailurePolicy` 필드가 설정되어 있다면, 잡 컨트롤러는 종료 중인 +파드(`.metadata.deletionTimestamp` 필드가 설정된 파드)가 종료 상태(`.status.phase` 값이 `Failed` 혹은 `Succeeded`)가 될 때 까지 +해당 파드를 실패로 간주하지 않는다. 그러나, 잡 컨트롤러는 +파드가 명백히 종료되었다고 판단하면 곧바로 대체 파드를 생성한다. +파드가 한 번 종료되면, 잡 컨트롤러는 방금 종료된 파드를 고려하여 +관련 작업에 대해 `.backoffLimit`과 `.podFailurePolicy`를 평가한다. + +이러한 조건들이 하나라도 충족되지 않을 경우, 잡 컨트롤러는 +종료 중인 파드가 추후 `phase: "Succeded"`로 종료된다고 할지라도, +해당 파드를 실패한 파드로 즉시 간주한다. + ### 파드 백오프(backoff) 실패 정책 구성에 논리적 오류가 포함되어 있어서 몇 회의 재시도 이후에 @@ -313,10 +332,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 계산 중 하나가 `.spec.backoffLimit`에 도달하면, 잡이 실패한 것으로 간주한다. -[`JobTrackingWithFinalizers`](#종료자-finalizers-를-이용한-잡-추적) 기능이 비활성화되어 -있다면, 실패한 파드의 수는 API에 여전히 표시되고 있는 파드로만 -계산된다. - {{< note >}} 만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에 도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이 @@ -461,12 +476,13 @@ spec: 여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다. 패턴 이름은 예시와 더 자세한 설명을 위한 링크이다. -| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? | -| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| -| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 | -| [가변 파드 수를 가진 큐] | ✓ | ✓ | | -| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ | -| [잡 템플릿 확장] | | | ✓ | +| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? | +| ----------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| +| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 | +| [가변 파드 수를 가진 큐] | ✓ | ✓ | | +| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ | +| [잡 템플릿 확장] | | | ✓ | +| [파드 간 통신을 위한 잡] | ✓ | 때때로 | 때때로 | `.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는 동일한 [`사양`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)을 갖는다. 이 의미는 @@ -477,17 +493,19 @@ spec: 이 표는 각 패턴에 필요한 `.spec.parallelism` 그리고 `.spec.completions` 설정을 보여준다. 여기서 `W` 는 작업 항목의 수이다. -| 패턴 | `.spec.completions` | `.spec.parallelism` | -| ----------------------------------------- |:-------------------:|:--------------------:| -| [작업 항목 당 파드가 있는 큐] | W | any | -| [가변 파드 수를 가진 큐] | null | any | -| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any | -| [잡 템플릿 확장] | 1 | 1이어야 함 | +| 패턴 | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------- |:-------------------:|:--------------------:| +| [작업 항목 당 파드가 있는 큐] | W | any | +| [가변 파드 수를 가진 큐] | null | any | +| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any | +| [잡 템플릿 확장] | 1 | 1이어야 함 | +| [파드 간 통신을 위한 잡] | W | W | [작업 항목 당 파드가 있는 큐]: /ko/docs/tasks/job/coarse-parallel-processing-work-queue/ [가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/ [정적 작업 할당을 사용한 인덱싱된 잡]: /ko/docs/tasks/job/indexed-parallel-processing-static/ [잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/ +[파드 간 통신을 위한 잡]: /docs/tasks/job/job-with-pod-to-pod-communication/ ## 고급 사용법 @@ -697,7 +715,7 @@ spec: ### 파드 실패 정책{#pod-failure-policy} -{{< feature-state for_k8s_version="v1.25" state="alpha" >}} +{{< feature-state for_k8s_version="v1.26" state="beta" >}} {{< note >}} 잡(Job)에 대한 파드 실패 정책은 @@ -706,7 +724,7 @@ spec: 파드 장애 정책의 파드 중단 조건 (참조: [파드 중단 조건](/ko/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions))을 감지하고 처리할 수 있도록 `PodDisruptionConditions` 기능 게이트를 활성화하는 것을 권장한다. 두 기능 게이트 모두 -쿠버네티스 v1.25에서 사용할 수 있다. +쿠버네티스 {{< skew currentVersion >}}에서 사용할 수 있다. {{< /note >}} `.spec.podFailurePolicy` 필드로 정의되는 파드 실패 정책은, 클러스터가 @@ -780,43 +798,33 @@ kubelet은 특정 파드에서 `main` 컨테이너를 재시작하지 않는다. ### 종료자(finalizers)를 이용한 잡 추적 -{{< feature-state for_k8s_version="v1.23" state="beta" >}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} {{< 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/)를 활성화해야 한다. - -이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. -이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다. -사용자가 느낄 수 있는 유일한 차이점은 -컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. +컨트롤 플레인을 1.26으로 업그레이드하더라도, +기능 게이트 `JobTrackingWithFinalizers`가 비활성화되어 있을 때 생성된 잡이라면, +컨트롤 플레인은 종료자를 사용하는 잡을 추적하지 않는다. {{< /note >}} -이 기능이 활성화되지 않으면, 잡 -{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 -`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다. -그런데, 파드는 다음과 같은 이유로 제거될 수 있다. -- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거 -- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를 - 일정 임계값 이후에 제거 -- 잡에 속한 파드를 사용자가 임의로 제거 -- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나 - 교체 +컨트롤 플레인은 잡에 속한 파드들을 계속 추적하고, +API 서버로부터 제거된 파드가 있는지에 대해 알려준다. 이를 위해 잡 컨트롤러는 +`batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. +컨트롤러는 파드가 잡 상태로 처리된 이후에만 종료자를 제거하여, +다른 컨트롤러나 사용자가 파드를 제거할 수 있도록 한다. -클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면, -컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고 -API 서버에서 파드가 제거되면 이를 알아챈다. -이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. -컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로, -이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다. +쿠버네티스를 1.26으로 업그레이드하기 전이나, 기능 게이트 +`JobTrackingWithFinalizers`를 활성화시키기 전에 생성한 잡은 파드 종료자를 사용하지 않고 +추적된다. +잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 +클러스터에 존재하는 파드들에 대해서만 `succeded`와 `failed` 파드들에 대한 상태 카운터를 갱신한다. +만약 파드가 클러스터에서 제거된다면, +컨트롤 플레인은 잡의 진행 상황을 제대로 추적하지 못할 수 있다. -잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다. -이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다. -잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여, -잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다. -이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**. +잡이 `batch.kubernetes.io/job-tracking` 어노테이션을 가지고 있는지 확인함으로써 +컨트롤 플레인이 파드 종료자를 사용하여 잡을 추적하고 있는지 알 수 있다. +따라서 잡으로부터 이 어노테이션을 수동으로 추가하거나 제거해서는 **안 된다**. +그 대신, 파드 종료자를 사용하여 +추적이 가능한 잡을 재생성하면 된다. ## 대안 @@ -856,7 +864,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다. * 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다. * [작업 대기열을 사용한 거친 병렬 처리](/ko/docs/tasks/job/coarse-parallel-processing-work-queue/) * [작업 대기열을 사용한 정밀 병렬 처리](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) - * [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용 + * [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/) 사용 * 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/) * [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서 클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다. @@ -866,4 +874,5 @@ API 서버에서 파드가 제거되면 이를 알아챈다. 오브젝트 정의를 읽는다. * 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한 [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다. -* 단계별로 구성된 [예제](/docs/tasks/job/pod-failure-policy/)를 통해, `podFailurePolicy`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다. \ No newline at end of file +* 단계별로 구성된 [예제](/docs/tasks/job/pod-failure-policy/)를 통해, + `podFailurePolicy`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 9d22ae98f5..6f4134cb07 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -4,6 +4,13 @@ #- bprashanth #- madhusudancs title: 레플리카셋 +feature: + title: 자가 치유 + anchor: 레플리카셋 동작 방식 + description: > + 실패한 컨테이너를 재시작하고, 노드가 죽는 경우 컨테이너들을 교체하기 위해 다시 스케줄링을 하며, + 사용자가 정의한 상태 체크에 응답하지 않는 컨테이너들을 종료시키며, + 서비스를 제공할 준비가 완료될 때까지 해당 컨테이너를 클라이언트에 알리지 않는다. content_type: concept weight: 20 --- diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 862eb1aa25..4a9bdc7b2e 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -3,12 +3,6 @@ # - bprashanth # - janetkuo title: 레플리케이션 컨트롤러 -feature: - title: 자가 치유 - anchor: 레플리케이션 컨트롤러의 동작 방식 - description: > - 오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. - content_type: concept weight: 90 --- @@ -139,7 +133,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)만 허용되며, 특별히 지정되지 않으면 기본값이다. 로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다. -예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다. +예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)이다. ### 레플리케이션 컨트롤러에서 레이블 @@ -270,7 +264,7 @@ API 오브젝트에 대한 더 자세한 것은 ### 베어 파드 -사용자가 직접 파드를 만든 경우와 달리 레플리케이션 컨트롤러는 노드 오류 또는 커널 업그레이드와 같은 장애가 발생하는 노드 유지 관리의 경우와 같이 어떤 이유로든 삭제되거나 종료된 파드를 대체한다. 따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용하는 것이 좋다. 프로세스 관리자와 비슷하게 생각하면, 단지 단일 노드의 개별 프로세스가 아닌 여러 노드에서 여러 파드를 감독하는 것이다. 레플리케이션 컨트롤러는 로컬 컨테이너가 노드의 에이전트로 (예를 들어 Kubelet 또는 도커 ) 재시작하도록 위임한다. +사용자가 직접 파드를 만든 경우와 달리 레플리케이션 컨트롤러는 노드 오류 또는 커널 업그레이드와 같은 장애가 발생하는 노드 유지 관리의 경우와 같이 어떤 이유로든 삭제되거나 종료된 파드를 대체한다. 따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용하는 것이 좋다. 프로세스 관리자와 비슷하게 생각하면, 단지 단일 노드의 개별 프로세스가 아닌 여러 노드에서 여러 파드를 감독하는 것이다. 레플리케이션 컨트롤러는 로컬 컨테이너가 kubelet과 같은 노드의 에이전트로 재시작하도록 위임한다. ### 잡 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index b01aca022c..56286ae50b 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -144,8 +144,7 @@ spec: 문제 없이 실행되고 준비되는 최소 시간(초)을 나타내는 선택적인 필드이다. [롤링 업데이트](#롤링-업데이트) 전략을 사용할 때 롤아웃 진행 상황을 확인하는 데 사용된다. 이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) -파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 -[컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다. +파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다. ## 파드 신원 @@ -155,8 +154,23 @@ spec: ### 순서 색인 -N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있는 +N개의 [레플리카](#레플리카)가 있는 스테이트풀셋은 스테이트풀셋에 있는 각 파드에 0에서 N-1 까지의 정수가 순서대로 할당되며 해당 스테이트풀셋 내에서 고유 하다. +기본적으로 파드는 0부터 N-1까지의 순서대로 할당된다. + +### 시작 순서 + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +`.spec.ordinals`은 각 파드에 할당할 순서에 대한 +정수값을 설정할 수 있게 해주는 선택적인 필드로, 기본값은 nil이다. +이 필드를 사용하기 위해서는 +`StatefulSetStartOrdinal` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +활성화 시, 다음과 같은 옵션들을 설정할 수 있다. + +* `.spec.ordinals.start`: 만약 `.spec.ordinals.start` 필드가 세팅되지 않을 경우, 파드는 + `.spec.ordinals.start` 부터 + `.spec.ordinals.start + .spec.replicas - 1`의 순서대로 할당된다. ### 안정적인 네트워크 신원 @@ -215,7 +229,7 @@ PersistentVolumeClaim을 받는다. 위의 nginx 예시에서 각 파드는 `my- ### 파드 이름 레이블 -스테이트풀셋 {{< glossary_tooltip term_id="controller" >}} +스테이트풀셋 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` 레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 연결할 수 있다. @@ -351,7 +365,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 선택적 필드인 `.spec.persistentVolumeClaimRetentionPolicy` 는 스테이트풀셋의 생애주기동안 PVC를 삭제할 것인지, 삭제한다면 어떻게 삭제하는지를 관리한다. -이 필드를 사용하려면 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +이 필드를 사용하려면 API 서버와 컨트롤러 매니저에 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 활성화 시, 각 스테이트풀셋에 대해 두 가지 정책을 설정할 수 있다. `whenDeleted` diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 2338eccc4c..aa3ca80a64 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -39,12 +39,10 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) {{< /note >}} 파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 -도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. -파드의 콘텍스트 내에서 개별 애플리케이션은 -추가적으로 하위 격리가 적용된다. +{{< glossary_tooltip text="컨테이너" term_id="container" >}}를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. +파드의 콘텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용된다. -도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 -있는 도커 컨테이너 그룹과 비슷하다. +파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 컨테이너들의 집합과 비슷하다. ## 파드의 사용 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index c53dd81358..9a8d14ec26 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -229,7 +229,12 @@ drain 커멘드는 `pod-b` 를 축출하는데 성공했다. ## 파드 중단 조건 {#pod-disruption-conditions} -{{< feature-state for_k8s_version="v1.25" state="alpha" >}} +{{< feature-state for_k8s_version="v1.26" state="beta" >}} + +{{< note >}} +만약 쿠버네티스 {{< skew currentVersion >}} 보다 낮은 버전을 사용하고 있다면, +해당 버전의 문서를 참조하자. +{{< /note >}} {{< note >}} 클러스터에서 이 동작을 사용하려면 `PodDisruptionConditions` @@ -254,6 +259,9 @@ drain 커멘드는 `pod-b` 를 축출하는데 성공했다. `DeletionByPodGC` : 더 이상 존재하지 않는 노드에 바인딩된 파드는 [파드의 가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)에 의해 삭제될 예정이다. +`TerminationByKubelet` +: {{}} 또는 [그레이스풀 노드 셧다운](/ko/docs/concepts/architecture/nodes/#graceful-node-shutdown)으로 인해 kubelet이 파드를 종료시켰다. + {{< note >}} 파드 중단은 중단될 수 있다. 컨트롤 플레인은 동일한 파드의 중단을 계속 다시 시도하지만, 파드의 중단이 보장되지는 않는다. 결과적으로, diff --git a/content/ko/docs/concepts/workloads/pods/downward-api.md b/content/ko/docs/concepts/workloads/pods/downward-api.md index 8d458f52d4..4e046a8aeb 100644 --- a/content/ko/docs/concepts/workloads/pods/downward-api.md +++ b/content/ko/docs/concepts/workloads/pods/downward-api.md @@ -1,6 +1,7 @@ --- title: 다운워드(Downward) API content_type: concept +weight: 170 description: > 실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다. 환경 변수를 활용하거나, 그리고 특수한 볼륨 타입으로 채워진 파일을 이용한다. diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 4d1a0d80c5..a3e7f6b026 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -52,6 +52,10 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 일반 컨테이너와 마찬가지로, 사용자는 임시 컨테이너를 파드에 추가한 이후에 변경하거나 제거할 수 없다. +{{< note >}} +임시 컨테이너는 [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)에서 지원되지 않는다. +{{< /note >}} + ## 임시 컨테이너의 사용 임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에 diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index ad4dfa1b57..e868cf4657 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -186,8 +186,8 @@ Events: 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" - 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] - 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container init-myservice + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container init-myservice ``` 파드의 초기화 컨테이너의 상태를 보기 위해, 다음을 실행한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 1c42f27982..d65f4405b8 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -258,10 +258,14 @@ Kubelet이 파드에 네트워킹이 구성된 런타임 샌드박스가 런타임 플러그인이 파드를 위한 샌드박스 생성 및 네트워크 구성을 성공적으로 완료하면 kubelet이 `PodHasNetwork` 컨디션을 `True`로 설정한다. -`PodHasNetwork` 컨디션이 `True`로 설정되면 kubelet이 컨테이너 이미지를 풀링하고 컨테이너를 생성할 수 있다. +`PodHasNetwork` 컨디션이 `True`로 설정되면 +kubelet이 컨테이너 이미지를 풀링하고 컨테이너를 생성할 수 있다. -초기화 컨테이너가 있는 파드의 경우, kubelet은 초기화 컨테이너가 성공적으로 완료(런타임 플러그인에 의한 성공적인 샌드박스 생성 및 네트워크 구성이 완료되었음을 의미)된 후 `Initialized` 컨디션을 `True`로 설정한다. -초기화 컨테이너가 없는 파드의 경우, kubelet은 샌드박스 생성 및 네트워크 구성이 시작되기 전에 `Initialized` 컨디션을 `True`로 설정한다. +초기화 컨테이너가 있는 파드의 경우, kubelet은 초기화 컨테이너가 +성공적으로 완료(런타임 플러그인에 의한 성공적인 샌드박스 생성 및 네트워크 구성이 완료되었음을 의미)된 후 +`Initialized` 컨디션을 `True`로 설정한다. +초기화 컨테이너가 없는 파드의 경우, kubelet은 샌드박스 생성 및 네트워크 구성이 +시작되기 전에 `Initialized` 컨디션을 `True`로 설정한다. ## 컨테이너 프로브(probe) @@ -459,7 +463,7 @@ TERM 대신 이 값을 보낸다. 1. kubelet이 정상 종료를 시작하는 동시에, 컨트롤 플레인은 구성된 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 있는 {{< glossary_tooltip term_id="service" text="서비스" >}}를 나타내는 - 엔드포인트(Endpoint)(그리고, 활성화된 경우, 엔드포인트슬라이스(EndpointSlice)) 오브젝트에서 종료된 파드를 제거한다. + 엔드포인트슬라이스(EndpointSplice)(그리고 엔드포인트) 오브젝트에서 종료된 파드를 제거한다. {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}과 기타 워크로드 리소스는 더 이상 종료된 파드를 유효한 서비스 내 복제본으로 취급하지 않는다. 로드 밸런서(서비스 프록시와 같은)가 종료 유예 기간이 _시작되는_ 즉시 엔드포인트 목록에서 파드를 제거하므로 느리게 종료되는 @@ -495,21 +499,35 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파 있다. 노드에서 즉시 종료되도록 설정된 파드는 강제 종료되기 전에 작은 유예 기간이 계속 제공된다. +{{< caution >}} +즉시 제거는 실행 중인 자원이 정상적으로 종료되는 것을 보장하지 않는다. 자원은 클러스터에서 영원히 회수되지 않을 수 있다. +{{< /caution >}} + 스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우, [스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 태스크 문서를 참고한다. -### 종료된 파드의 가비지 콜렉션 {#pod-garbage-collection} +### 파드의 가비지 콜렉션 {#pod-garbage-collection} 실패한 파드의 경우, API 오브젝트는 사람이나 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 프로세스가 명시적으로 파드를 제거할 때까지 클러스터의 API에 남아 있다. -컨트롤 플레인은 파드 수가 구성된 임계값(kube-controller-manager에서 +컨트롤 플레인에서의 컨트롤러 역할인 파드 가비지 콜렉터(PodGC)는, 파드 수가 구성된 임계값(kube-controller-manager에서 `terminated-pod-gc-threshold` 에 의해 결정됨)을 초과할 때 종료된 파드(`Succeeded` 또는 `Failed` 단계 포함)를 정리한다. 이렇게 하면 시간이 지남에 따라 파드가 생성되고 종료될 때 리소스 유출이 방지된다. +추가적으로 PodGC는 다음과 같은 조건들 중 하나라도 만족하는 파드들을 정리한다. +1. 고아 파드 - 더 이상 존재하지 않는 노드에 종속되어있는 파드이거나, +2. 스케줄되지 않은 종료 중인 파드이거나, +3. `NodeOutOfServiceVolumeDetach` 기능 게이트가 활성화되어 있을 때, [`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service)에 테인트된 준비되지 않은 노드에 속한 종료 중인 파드인 경우에 적용된다. + +`PodDisruptionConditions` 기능 게이트가 활성화된 경우, PodGC는 +파드를 정리하는 것 뿐만 아니라 해당 파드들이 non-terminal 단계에 있는 경우 +그들을 실패했다고 표시하기도 한다. +또한, PodGC는 고아 파드를 정리할 때 파드 중단 조건을 추가하기도 한다. +(자세한 내용은 [파드 중단 조건](/ko/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)을 확인한다.) ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/workloads/pods/user-namespaces.md b/content/ko/docs/concepts/workloads/pods/user-namespaces.md index 309045066d..a42a88e2dd 100644 --- a/content/ko/docs/concepts/workloads/pods/user-namespaces.md +++ b/content/ko/docs/concepts/workloads/pods/user-namespaces.md @@ -90,8 +90,8 @@ kubelet은 동일 노드에 있는 두 개의 스테이트리스 파드가 동 컨테이너 내부에서 프로세스는 자신이 루트로 실행된다고 생각하지만 (따라서 `apt`, `yum` 등과 같은 도구가 정상적으로 작동) 실제로 프로세스는 호스트에 대한 권한이 없다. -예를 들어, 컨테이너 프로세스가 호스트에서 `ps`를 실행하고 -있는 사용자를 확인하는 경우 이를 확인 할 수 있다. +예를 들어, 호스트에서 `ps aux`를 실행함으로써 +컨테이너 프로세스가 어느 사용자에 의해 실행 중인지 확인할 수 있다. 사용자 `ps`는 컨테이너 안에서 명령 `id`를 실행하면 나타나는 사용자와 동일하지 않다. 이 추상화는 컨테이너가 호스트로 탈출하는 것과 같은 상황을 제한한다. From d0d022b75c7eb6af6995c5e89cb2026e8d730caa Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Sat, 11 Mar 2023 16:23:29 +0900 Subject: [PATCH 22/69] [ko] translate extended-resource.md into Korean --- .../extended-resource.md | 145 ++++++++++++++++++ .../resource/extended-resource-pod-2.yaml | 13 ++ .../pods/resource/extended-resource-pod.yaml | 13 ++ 3 files changed, 171 insertions(+) create mode 100644 content/ko/docs/tasks/configure-pod-container/extended-resource.md create mode 100644 content/ko/examples/pods/resource/extended-resource-pod-2.yaml create mode 100644 content/ko/examples/pods/resource/extended-resource-pod.yaml diff --git a/content/ko/docs/tasks/configure-pod-container/extended-resource.md b/content/ko/docs/tasks/configure-pod-container/extended-resource.md new file mode 100644 index 0000000000..3e54b7bef8 --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/extended-resource.md @@ -0,0 +1,145 @@ +--- +title: 컨테이너에 확장 리소스 지정 +content_type: task +weight: 40 +--- + + + +{{< feature-state state="stable" >}} + +이 페이지는 컨테이너에 확장 리소스를 지정하는 방법을 보여준다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +이 태스크를 수행하기 전에 +[노드에 대한 확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에서 연습한다. +그러면 노드 중 하나가 동글(dongle) 리소스를 알리도록 구성될 것이다. + + + + + + +## 파드에 확장 리소스 지정 + +확장 리소스를 요청하려면 컨테이너 매니페스트에 `resources:requests` 필드를 포함한다. +확장 리소스는 `*.kubernetes.io/` 외부의 모든 도메인으로 정규화된다. +유효한 확장 리소스 이름은 `example.com/foo` 형식을 갖는다. +여기서 `example.com`은 조직의 도메인으로 대체하고, +`foo`는 리소스를 설명할 수 있는 이름으로 짓는다. + +다음은 컨테이너가 하나 있는 파드의 구성 파일이다. + +{{< codenew file="pods/resource/extended-resource-pod.yaml" >}} + +구성 파일에서 컨테이너가 3개의 동글을 요청하는 것을 알 수 있다. + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml +``` + +파드가 실행 중인지 확인한다. + +```shell +kubectl get pod extended-resource-demo +``` + +파드의 상세 정보를 확인한다. + +```shell +kubectl describe pod extended-resource-demo +``` + +출력은 동글 요청을 보여준다. + +```yaml +Limits: + example.com/dongle: 3 +Requests: + example.com/dongle: 3 +``` + +## 두 번째 파드 생성 시도 + +다음은 컨테이너가 하나 있는 파드의 구성 파일이다. +컨테이너는 두 개의 동글을 요청한다. + +{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}} + +첫 번째 파드가 사용 가능한 4개의 동글 중 3개를 사용했기 때문에 +쿠버네티스는 두 개의 동글에 대한 요청을 충족시킬 수 없을 것이다. + +파드 생성을 시도한다. + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml +``` + +파드 상세 정보를 확인한다. + +```shell +kubectl describe pod extended-resource-demo-2 +``` + +출력은 두 개의 동글을 가용할 수 있는 노드가 없기 때문에 +파드를 스케줄할 수 없음을 보여준다. + + +``` +Conditions: + Type Status + PodScheduled False +... +Events: + ... + ... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node +fit failure summary on nodes : Insufficient example.com/dongle (1) +``` + +파드 상태를 확인한다. + +```shell +kubectl get pod extended-resource-demo-2 +``` + +출력은 파드가 생성됐지만 노드에서 실행되도록 스케줄되지 않았음을 보여준다. +파드는 Pending 상태이다. + +```yaml +NAME READY STATUS RESTARTS AGE +extended-resource-demo-2 0/1 Pending 0 6m +``` + +## 정리 + +연습을 위해 생성한 파드를 삭제한다. + +```shell +kubectl delete pod extended-resource-demo +kubectl delete pod extended-resource-demo-2 +``` + + + +## {{% heading "whatsnext" %}} + + +### 애플리케션 개발자들을 위한 문서 + +* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) + +### 클러스터 관리자들을 위한 문서 + +* [노드에 확장된 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/) + + diff --git a/content/ko/examples/pods/resource/extended-resource-pod-2.yaml b/content/ko/examples/pods/resource/extended-resource-pod-2.yaml new file mode 100644 index 0000000000..9c15d9ec86 --- /dev/null +++ b/content/ko/examples/pods/resource/extended-resource-pod-2.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: extended-resource-demo-2 +spec: + containers: + - name: extended-resource-demo-2-ctr + image: nginx + resources: + requests: + example.com/dongle: 2 + limits: + example.com/dongle: 2 diff --git a/content/ko/examples/pods/resource/extended-resource-pod.yaml b/content/ko/examples/pods/resource/extended-resource-pod.yaml new file mode 100644 index 0000000000..4fb3de740e --- /dev/null +++ b/content/ko/examples/pods/resource/extended-resource-pod.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: extended-resource-demo +spec: + containers: + - name: extended-resource-demo-ctr + image: nginx + resources: + requests: + example.com/dongle: 3 + limits: + example.com/dongle: 3 From 7204634c03ec8cf4dc0ae446a82c0a87b165cf6b Mon Sep 17 00:00:00 2001 From: jongwooo Date: Fri, 3 Mar 2023 00:27:17 +0900 Subject: [PATCH 23/69] [ko] Update outdated files in dev-1.26-ko.1 (M45-M57) Signed-off-by: jongwooo --- .../concepts/scheduling-eviction/_index.md | 4 +++- .../scheduling-eviction/api-eviction.md | 2 +- .../scheduling-eviction/assign-pod-node.md | 14 ++++++------- .../scheduling-eviction/kube-scheduler.md | 10 +++++----- .../node-pressure-eviction.md | 10 ++++++++-- .../pod-priority-preemption.md | 2 +- .../scheduler-perf-tuning.md | 2 +- .../taint-and-toleration.md | 2 +- .../topology-spread-constraints.md | 20 +++++++++---------- content/ko/docs/concepts/security/_index.md | 2 +- .../docs/concepts/security/multi-tenancy.md | 13 ++++++------ content/ko/docs/concepts/security/overview.md | 10 +++++----- .../concepts/security/pod-security-policy.md | 10 +++------- 13 files changed, 52 insertions(+), 49 deletions(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index 0efcb3822e..be67137582 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -1,6 +1,6 @@ --- title: "스케줄링, 선점(Preemption), 축출(Eviction)" -weight: 90 +weight: 95 content_type: concept description: > 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 @@ -26,8 +26,10 @@ no_list: true * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/) * [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/) * [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/) +* [동적 리소스 할당](/docs/concepts/scheduling-eviction/dynamic-resource-allocation) * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/) +* [파드 스케줄링 준비성(readiness)](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) ## 파드 중단(disruption) diff --git a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md index 8368be9831..d8333273d4 100644 --- a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md @@ -1,7 +1,7 @@ --- title: API를 이용한 축출(API-initiated Eviction) content_type: concept -weight: 70 +weight: 110 --- {{< glossary_definition term_id="api-eviction" length="short" >}}
    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 c5be6df5bb..7826d3b082 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -2,7 +2,7 @@ # reviewers: # - davidopp # - kevin-wangzefeng -# - bsalamat +# - alculquicondor title: 노드에 파드 할당하기 content_type: concept weight: 20 @@ -144,13 +144,13 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 `nodeSelector`와 `nodeAffinity`를 모두 사용하는 경우, 파드가 노드에 스케줄링되려면 두 조건 *모두* 만족되어야 한다. -`nodeAffinity`에 연결된 `nodeSelectorTerms`를 여러 개 명시한 경우, -명시된 `nodeSelectorTerms` 중 하나를 만족하는 노드에도 -파드가 스케줄링될 수 있다. +`nodeAffinity`의 `nodeSelectorTerms`에 여러 조건(term)을 명시한 경우, +노드가 명시된 조건 중 하나만 만족해도 파드가 +해당 노드에 스케줄링될 수 있다. (조건들은 OR 연산자로 처리) -단일 `nodeSelectorTerms`와 연결된 `matchExpressions`를 여러 개 명시한 경우, -모든 `matchExpressions`를 만족하는 노드에만 -파드가 스케줄링될 수 있다. +`nodeSelectorTerms`의 조건으로 단일 `matchExpressions` 필드에 여러 표현식(expression)을 명시한 경우, +모든 표현식을 동시에 만족하는 노드에만 +파드가 스케줄링될 수 있다. (표현식들은 AND 연산자로 처리) {{}} [노드 어피니티를 사용해 노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)에서 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index ebc73da3f3..e5ab4ca5f6 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -32,11 +32,11 @@ weight: 10 kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를 만들고 대신 사용할 수 있도록 설계되었다. -새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 kube-scheduler는 -실행할 최적의 노드를 선택한다. 그러나 파드의 모든 컨테이너에는 -리소스에 대한 요구사항이 다르며 모든 파드에도 -요구사항이 다르다. 따라서 기존 노드들은 -특정 스케줄링 요구사항에 따라 필터링 되어야 한다. +kube-scheduler는 새로 생성되었거나 아직 +예약되지 않은(스케줄링되지 않은) 파드를 실행할 최적의 노드를 선택한다. 파드의 컨테이너와 파드 자체는 +서로 다른 요구사항을 가질 수 있으므로, 스케줄러는 파드의 특정 스케줄링 요구사항을 +충족하지 않는 모든 노드를 필터링한다. 또는 API를 사용하면 파드를 생성할 때 노드를 지정할 수 있지만, 이는 드문 경우이며 +특별한 경우에만 수행된다. 클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를 _실행 가능한(feasible)_ 노드라고 한다. 적합한 노드가 없으면 스케줄러가 diff --git a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md index e567d98b6a..85556c6ca2 100644 --- a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md +++ b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -1,13 +1,13 @@ --- title: 노드-압박 축출 content_type: concept -weight: 60 +weight: 100 --- {{}}
    {{}}은 -클러스터 노드의 CPU, 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다. +클러스터 노드의 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다. 이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면, kubelet은 하나 이상의 파드를 능동적으로 중단시켜 자원을 회수하고 고갈 상황을 방지할 수 있다. @@ -154,6 +154,12 @@ kubelet은 다음과 같은 하드 축출 임계값을 기본적으로 설정하 * `imagefs.available<15%` * `nodefs.inodesFree<5%` (리눅스 노드) +이러한 하드 축출 임계값의 기본값은 +매개변수가 변경되지 않은 경우에만 설정된다. 어떤 매개변수의 값을 변경한 경우, +다른 매개변수의 값은 기본값으로 상속되지 않고 +0으로 설정된다. 사용자 지정 값을 제공하려면, +모든 임계값을 각각 제공해야 한다. + ### 축출 모니터링 시간 간격 kubelet은 `housekeeping-interval`에 설정된 시간 간격(기본값: `10s`)마다 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 4d2754c718..92d7611d03 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -4,7 +4,7 @@ # - wojtek-t title: 파드 우선순위(priority)와 선점(preemption) content_type: concept -weight: 70 +weight: 90 --- 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 6c41b4c4b0..2ff8f4a14a 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -3,7 +3,7 @@ # - bsalamat title: 스케줄러 성능 튜닝 content_type: concept -weight: 100 +weight: 70 --- 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 505ea5896b..5c28b579a2 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -5,7 +5,7 @@ # - bsalamat title: 테인트(Taints)와 톨러레이션(Tolerations) content_type: concept -weight: 40 +weight: 50 --- diff --git a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md index b831f73f46..fb560b5d49 100644 --- a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -45,7 +45,6 @@ weight: 40 파드 토폴로지 분배 제약 조건은 이러한 설정을 할 수 있도록 하는 선언적인 방법을 제공한다. - ## `topologySpreadConstraints` 필드 파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 이 필드는 다음과 같이 @@ -66,8 +65,8 @@ spec: whenUnsatisfiable: labelSelector: matchLabelKeys: # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. - nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. - nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. + nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다. + nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다. ### 파드의 다른 필드가 이 아래에 오게 된다. ``` @@ -99,7 +98,7 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 {{< note >}} `minDomains` 필드는 1.25에서 기본적으로 사용하도록 설정된 베타 필드이다. 사용을 원하지 않을 경우 - `MinDomainsInPodToplogySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다. + `MinDomainsInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다. {{< /note >}} - `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다. @@ -158,9 +157,9 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 옵션의 값이 null일 경우, Honor 정책과 동일하게 동작한다. {{< note >}} - `nodeAffinityPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면 + `nodeAffinityPolicy` 필드는 베타 필드이고 1.26에서 기본적으로 활성화되어 있다. 이 필드를 비활성화하려면 `NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) - 를 활성화시켜야 한다. + 를 비활성화하면 된다. {{< /note >}} - **nodeTaintsPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 노드 테인트(taint)를 @@ -172,9 +171,9 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 옵션의 값이 null일 경우, Ignore 정책과 동일하게 동작한다. {{< note >}} - `nodeTaintsPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면 + `nodeTaintsPolicy` 필드는 베타 필드이고 1.26에서 기본적으로 활성화되어 있다. 이 필드를 비활성화하려면 `NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) - 를 활성화시켜야 한다. + 를 비활성화하면 된다. {{< /note >}} 파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, @@ -202,7 +201,6 @@ kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노 모두 우리의 생각과 같을 것이라고 가정할 수는 없다. {{< /note >}} - 각각 다음과 같은 레이블을 갖는 4개의 노드로 구성된 클러스터가 있다고 가정한다. ``` @@ -496,7 +494,7 @@ class zoneC cluster; 기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)내의 플러그인 인자 중 하나로 설정할 수 있다. -제약 조건은 [위에서 설명한 것과 동일한 API](#api)를 이용하여 정의되는데, +제약 조건은 [위에서 설명한 것과 동일한 API](#topologyspreadconstraints-필드)를 이용하여 정의되는데, 다만 `labelSelector`는 비워 두어야 한다. 셀렉터는 파드가 속한 서비스, 레플리카셋, 스테이트풀셋, 또는 레플리케이션 컨트롤러를 바탕으로 계산한다. @@ -581,6 +579,7 @@ profiles: `podAffinity` : 파드를 끌어당긴다. 조건이 충족되는 토폴로지 도메인에는 원하는 수의 파드를 얼마든지 채울 수 있다. + `podAntiAffinity` : 파드를 밀어낸다. 이를 `requiredDuringSchedulingIgnoredDuringExecution` 모드로 설정하면 @@ -616,7 +615,6 @@ profiles: 전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는 클러스터 오토스케일링 도구를 이용할 수 있다. - ## {{% heading "whatsnext" %}} - [블로그: PodTopologySpread 소개](/blog/2020/05/introducing-podtopologyspread/)에서는 diff --git a/content/ko/docs/concepts/security/_index.md b/content/ko/docs/concepts/security/_index.md index d71d63c77a..e83283e819 100644 --- a/content/ko/docs/concepts/security/_index.md +++ b/content/ko/docs/concepts/security/_index.md @@ -1,6 +1,6 @@ --- title: "보안" -weight: 81 +weight: 85 description: > 클라우드 네이티브 워크로드를 안전하게 유지하기 위한 개념 --- diff --git a/content/ko/docs/concepts/security/multi-tenancy.md b/content/ko/docs/concepts/security/multi-tenancy.md index e91f159b9f..627d485f58 100755 --- a/content/ko/docs/concepts/security/multi-tenancy.md +++ b/content/ko/docs/concepts/security/multi-tenancy.md @@ -1,7 +1,7 @@ --- title: 멀티 테넌시(multi-tenancy) content_type: concept -weight: 70 +weight: 80 --- @@ -27,7 +27,7 @@ _멀티 테넌시_ 라는 포괄적 용어로 통칭한다. 사용 가능한 패턴과 툴을 산정하기 위해 유스케이스를 이해하는 것이다. 일반적으로 쿠버네티스에서의 멀티 테넌시는 다양한 형태로 변형 또는 혼합이 가능하지만, 넓게는 두 가지 범주로 분류된다. -### 다수의 팀 +### 다수의 팀 흔히 사용하는 멀티 테넌시의 형태는 하나 또는 그 이상의 워크로드를 운영하는 한 조직 소속의 여러 팀이 하나의 클러스터를 공유하는 형태이다. 이러한 워크로드는 @@ -39,7 +39,7 @@ GitOps 컨트롤러 혹은 다른 종류의 배포 자동화 툴을 통해 간 안전하고 공평한 클러스터 공유를 위해서는 RBAC, 쿼터(quota), 네트워크 정책과 같은 쿠버네티스 정책이 필수이다. -### 다수의 고객 +### 다수의 고객 다른 주요 멀티 테넌시 형태로는 서비스형소프트웨어(SaaS) 사업자가 여러 고객의 워크로드 인스턴스를 실행하는 것과 관련이 있다. @@ -217,8 +217,10 @@ _소란스러운 이웃_ 문제를 예방하기 위한 목적을 가지고 있 의해 제어될 수 있다. 테넌트 간의 엄격한 네트워크 격리가 필요한 멀티 테넌트 환경에서는, 파드 간의 통신을 거부하는 기본 정책과 모든 파드가 네임 해석(name resolution)을 위해 DNS 서버를 쿼리하도록 하는 규칙을 시작에 설정하는 것을 권고한다. 이러한 기본 정책을 -기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다. 이러한 -방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에 +기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다. +또한 네임스페이스 간에 트래픽을 허용해야 하는 경우 네트워크 정책 정의의 +namespaceSelector 필드에 빈 레이블 셀렉터 '{}'를 사용하지 않는 것이 좋다. +이러한 방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에 대해서만 적용된다는 것을 알아두어야 한다. 서로 다른 가상의 컨트롤 플레인에 소속된 파드는 쿠버네티스 네트워킹을 통해 통신할 수 없다. @@ -513,4 +515,3 @@ _가상 컨트롤 플레인_ 이라고 부른다. * [Kamaji](https://github.com/clastix/kamaji) * [vcluster](https://github.com/loft-sh/vcluster) - diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index bc9d9763de..83b4f98885 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -56,13 +56,13 @@ weight: 1 IaaS 공급자 | 링크 | -------------------- | ------------ | Alibaba Cloud | https://www.alibabacloud.com/trust-center | -Amazon Web Services | https://aws.amazon.com/security/ | -Google Cloud Platform | https://cloud.google.com/security/ | -Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html | +Amazon Web Services | https://aws.amazon.com/security | +Google Cloud Platform | https://cloud.google.com/security | +Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | -Oracle Cloud Infrastructure | https://www.oracle.com/security/ | -VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | +Oracle Cloud Infrastructure | https://www.oracle.com/security | +VMware vSphere | https://www.vmware.com/security/hardening-guides.html | {{< /table >}} diff --git a/content/ko/docs/concepts/security/pod-security-policy.md b/content/ko/docs/concepts/security/pod-security-policy.md index f30c57d79b..9106798b50 100644 --- a/content/ko/docs/concepts/security/pod-security-policy.md +++ b/content/ko/docs/concepts/security/pod-security-policy.md @@ -1,7 +1,4 @@ --- -# reviewers: -# - liggitt -# - tallclair title: 파드 시큐리티 폴리시 content_type: concept weight: 30 @@ -9,11 +6,11 @@ weight: 30 -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -{{< note >}} +{{% alert title="제거된 기능" color="warning" %}} 파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 1.21 버전부터 [사용 중단(deprecated)](/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation)되었으며, v1.25 버전 때 쿠버네티스에서 제거되었다. +{{% /alert %}} + 파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을 적용할 수 있다. @@ -26,4 +23,3 @@ v1.25 버전 때 쿠버네티스에서 제거되었다. 쿠버네티스 v{{< skew currentVersion >}} 이외의 버전을 실행 중이라면, 해당 쿠버네티스 버전에 대한 문서를 확인한다. -{{< /note >}} From 4d840fb4b241e342bc2229b3b44a6dc8f73b6198 Mon Sep 17 00:00:00 2001 From: YujinChoi Date: Sun, 5 Mar 2023 09:15:25 +0900 Subject: [PATCH 24/69] [ko] Update outdated files in `dev-1.26-ko.1` (M62) --- .../services-networking/ingress-controllers.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index ad5c04c72b..1d94d88109 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -1,8 +1,12 @@ --- title: 인그레스 컨트롤러 -# reviewers: +description: >- + 클러스터 내의 [인그레스](/ko/docs/concepts/services-networking/ingress/)가 작동하려면, + 인그레스 컨트롤러가 실행되고 있어야 한다. + 적어도 하나의 인그레스 컨트롤러를 선택하고 이를 클러스터 내에 설치한다. + 이 페이지는 배포할 수 있는 일반적인 인그레스 컨트롤러를 나열한다. content_type: concept -weight: 40 +weight: 50 --- @@ -59,12 +63,11 @@ weight: 40 ## 여러 인그레스 컨트롤러 사용 -하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. -인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 -어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) -어노테이션을 각각의 인그레스에 달아야 한다. +하나의 클러스터 내에 [인그레스 클래스](/ko/docs/concepts/services-networking/ingress/#ingress-class)를 이용하여 여러 개의 인그레스 컨트롤러를 배포할 수 있다. +`.metadata.name` 필드를 확인해둔다. 인그레스를 생성할 때 인그레스 오브젝트([IngressSpec v1 참고](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec))의 `ingressClassName` 필드에 해당 이름을 명시해야 한다. `ingressClassName`은 이전 [어노테이션 방식](/ko/docs/concepts/services-networking/ingress/#사용중단-deprecated-어노테이션)의 대체 수단이다. -만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다. +인그레스에 대한 인그레스 클래스를 설정하지 않았고, 클러스터에 기본으로 설정된 인그레스 클래스가 정확히 하나만 존재하는 경우, 쿠버네티스는 클러스터의 기본 인그레스 클래스를 인그레스에 [적용](/ko/docs/concepts/services-networking/ingress/#default-ingress-class)한다. +인그레스 클래스에 [`ingressclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)을 문자열 값 `"true"`로 설정하여, 해당 인그레스 클래스를 기본으로 설정할 수 있다. 이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다. From 9908fdc61a2106da09ba603031ce27de732305c3 Mon Sep 17 00:00:00 2001 From: YujinChoi Date: Wed, 22 Mar 2023 22:58:20 +0900 Subject: [PATCH 25/69] [ko] Update outdated files in dev-1.26-ko.1 (M58) --- .../ko/docs/concepts/services-networking/_index.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md index 2ebb1a0b4a..3f277f0823 100644 --- a/content/ko/docs/concepts/services-networking/_index.md +++ b/content/ko/docs/concepts/services-networking/_index.md @@ -49,5 +49,15 @@ NAT 없이 모든 노드의 모든 파드와 통신할 수 있다. 쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다. - 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다. - 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다. -- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다. -- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다. +- [서비스](/ko/docs/concepts/services-networking/service/) API를 사용하면 + [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/tutorials/services/connect-applications-service/) + 할 수 있다. + - [인그레스](/ko/docs/concepts/services-networking/ingress/)는 + 특히 HTTP 애플리케이션, 웹사이트 그리고 API를 노출하기 위한 추가 기능을 제공한다. +- 또한 서비스를 사용하여 + [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다. + +- [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼에서는 실습 예제를 통해 서비스와 쿠버네티스 네트워킹에 대해 배울 수 있다. + +[클러스터 네트워킹](/ko/docs/concepts/cluster-administration/networking/)은 +클러스터에 네트워킹을 설정하는 방법과 관련된 기술에 대한 개요도 제공한다. \ No newline at end of file From cdd67a51ef50882dde46dee4d8c88faac76b8fe7 Mon Sep 17 00:00:00 2001 From: YujinChoi Date: Thu, 23 Mar 2023 20:47:52 +0900 Subject: [PATCH 26/69] [ko] Update outdated files in `dev-1.26-ko.1` (M63-M66) --- .../concepts/services-networking/ingress.md | 9 +++++++-- .../services-networking/network-policies.md | 7 ++++++- .../services-networking/service-topology.md | 11 +++-------- .../service-traffic-policy.md | 18 +++++++++--------- 4 files changed, 25 insertions(+), 20 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index f16f3a36de..3c2af7f1cb 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -3,7 +3,12 @@ # - bprashanth title: 인그레스(Ingress) content_type: concept -weight: 40 +description: >- + URI, 호스트네임, 경로 등과 같은 웹 개념을 이해하는 프로토콜-인지형(protocol-aware configuration) 설정 메커니즘을 이용하여 + HTTP (혹은 HTTPS) 네트워크 서비스를 사용 가능하게 한다. + 인그레스 개념은 쿠버네티스 API를 통해 정의한 규칙에 기반하여 트래픽을 다른 백엔드에 + 매핑할 수 있게 해준다. +weight: 30 --- @@ -95,7 +100,7 @@ weight: 40 보내기 전에 호스트와 경로가 모두 수신 요청의 내용과 일치해야 한다. * 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이 - 서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한 + 서비스와 포트 이름의 조합이다. 규칙의 호스트와 경로가 일치하는 인그레스에 대한 HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다. `defaultBackend` 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스 diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 4b550a04ff..362fa9d351 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -5,7 +5,12 @@ # - danwinship title: 네트워크 정책 content_type: concept -weight: 50 +weight: 70 +description: >- + IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, + 네트워크 정책은 클러스터 내의 트래픽 흐름뿐만 아니라 + 파드와 외부 간의 규칙을 정의할 수 있도록 해준다. + 클러스터는 반드시 네트워크 정책을 지원하는 네트워크 플러그인을 사용해야 한다. --- diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index fd25e14908..a503d60120 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -4,7 +4,7 @@ # - imroc title: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅 content_type: concept -weight: 10 +weight: 150 --- @@ -18,7 +18,6 @@ weight: 10 더 이상 사용되지 않는다. 쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)는 유사한 기능을 제공한다. - {{}} _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를 @@ -195,11 +194,7 @@ spec: - "*" ``` - - - ## {{% heading "whatsnext" %}} - -* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기. -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기. +* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)를 읽어보기. +* [서비스와 애플리케이션 연결하기](/docs/tutorials/services/connect-applications-service/)를 읽어보기. diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index d8de045fe6..16f59a4068 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -3,13 +3,18 @@ # - maplain title: 서비스 내부 트래픽 정책 content_type: concept -weight: 45 +weight: 120 +description: >- + 클러스터 내의 두 파드가 통신을 하려고 하고 두 파드가 동일한 노드에서 실행되는 경우, + _서비스 내부 트래픽 정책_을 사용하여 네트워크 트래픽을 해당 노드 안에서 유지할 수 있다. + 클러스터 네트워크를 통한 왕복 이동을 피하면 안전성, 성능 + (네트워크 지연 및 처리량) 혹은 비용 측면에 도움이 될 수 있다. --- -{{< feature-state for_k8s_version="v1.23" state="beta" >}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된 노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다. @@ -20,9 +25,6 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 ## 서비스 내부 트래픽 정책 사용 -`ServiceInternalTrafficPolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 -베타 기능이며 기본적으로 활성화되어 있다. -이 기능이 활성화되어 있으면, {{< glossary_tooltip text="서비스" term_id="service" >}}의 `.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다. 이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다. @@ -56,12 +58,10 @@ spec: kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되는 엔드포인트를 필터링한다. 이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다. -이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다. -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 -`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다. +이 설정이 `Cluster`(기본)이거나 설정되지 않았다면 모든 엔드포인트를 고려한다. ## {{% heading "whatsnext" %}} * [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 +* [서비스와 애플리케이션 연결하기](/docs/tutorials/services/connect-applications-service/) 를 따라하기 From 61c871362754e57f3eda970988d8afc341a0b449 Mon Sep 17 00:00:00 2001 From: namuk2004 Date: Thu, 23 Mar 2023 21:51:22 +0900 Subject: [PATCH 27/69] Translate tasks/administer-cluster/dns-horizontal-autoscaling in Korean Translate tasks/administer-cluster/dns-horizontal-autoscaling in Korean Translate tasks/debug/debug-application/debug-service in Korean Delete debug-service.md --- .../dns-horizontal-autoscaling.md | 236 ++++++++++++++++++ .../admin/dns/dns-horizontal-autoscaler.yaml | 88 +++++++ 2 files changed, 324 insertions(+) create mode 100644 content/ko/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md create mode 100644 content/ko/examples/admin/dns/dns-horizontal-autoscaler.yaml diff --git a/content/ko/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/ko/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md new file mode 100644 index 0000000000..607524e7f2 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -0,0 +1,236 @@ +--- +title: 클러스터에서 DNS 서비스 오토스케일 +content_type: task +--- + + +이 페이지는 쿠버네티스 클러스터에서 DNS 서비스의 오토스케일링을 구성하고 +활성화하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* 이 가이드는 노드가 AMD64 또는 인텔 64 CPU 아키텍처를 사용한다고 가정한다. + +* [Kubernetes DNS](/ko/docs/concepts/services-networking/dns-pod-service/)가 활성화되어 있는지 확인한다. + + + + + +## DNS 수평 오토스케일링이 이미 활성화되어 있는지 확인 {#determining-whether-dns-horizontal-autoscaling-is-already-enabled} + +kube-system {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}} +에서 클러스터의 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}를 나열한다. + +```shell +kubectl get deployment --namespace=kube-system +``` + +출력은 다음과 유사하다. + + NAME READY UP-TO-DATE AVAILABLE AGE + ... + dns-autoscaler 1/1 1 1 ... + ... + +해당 출력에서 "dns-autoscaler"가 표시되면, DNS 수평 오토스케일링이 +이미 활성화되어 있다는 의미이므로, +[오토스케일링 파라미터 조정](#tuning-autoscaling-parameters)으로 건너뛰면 된다. + +## DNS 디플로이먼트 이름 가져오기 {#find-scaling-target} + +kube-system 네임스페이스에서 클러스터의 DNS 디플로이먼트를 나열한다. + +```shell +kubectl get deployment -l k8s-app=kube-dns --namespace=kube-system +``` + +출력은 이와 유사하다. + + NAME READY UP-TO-DATE AVAILABLE AGE + ... + coredns 2/2 2 2 ... + ... + +DNS 서비스용 디플로이먼트가 표시되지 않으면, 이름으로 찾을 수 있다. + +```shell +kubectl get deployment --namespace=kube-system +``` + +그리고 `coredns` 또는 `kube-dns`라는 디플로이먼트를 찾는다. + + +스케일 대상은 + + Deployment/ + +이며, 여기서 ``는 DNS 디플로이먼트의 이름이다. 예를 들어, +DNS용 디플로이먼트 이름이 coredns인 경우, 스케일 대상은 Deployment/coredns이다. + +{{< note >}} +CoreDNS는 쿠버네티스의 기본 DNS 서비스이다. +CoreDNS는 본래 kube-dns로 사용한 클러스터에서 작동할 수 있도록 +`k8s-app=kube-dns`로 레이블을 설정한다. +{{< /note >}} + +## DNS 수평 오토스케일링 활성화 {#enablng-dns-horizontal-autoscaling} + +이 섹션에서는 새로운 디플로이먼트를 만든다. 디플로이먼트의 파드는 +`cluster-proportional-autoscaler-amd64` 이미지 기반의 컨테이너를 실행한다. + +다음의 내용으로 `dns-horizontal-autoscaler.yaml`라는 파일을 만든다. + +{{< codenew file="admin/dns/dns-horizontal-autoscaler.yaml" >}} + +파일에서, ``을 사용자의 스케일 대상으로 변경한다. + +구성 파일이 포함된 디렉토리로 이동하고, +디플로이먼트를 만들기 위해 다음의 커맨드를 입력한다. + +```shell +kubectl apply -f dns-horizontal-autoscaler.yaml +``` + +성공적인 커맨드의 출력은 다음과 같다. + + deployment.apps/dns-autoscaler created + +DNS 수평 오토스케일링이 활성화되었다. + +## DNS 오토스케일링 파라미터 조정 {#tuning-autoscaling-parameters} + +dns-autoscaler {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}이 있는지 확인한다. + +```shell +kubectl get configmap --namespace=kube-system +``` + +출력은 다음과 유사하다. + + NAME DATA AGE + ... + dns-autoscaler 1 ... + ... + +컨피그맵에서 데이터를 수정한다. + +```shell +kubectl edit configmap dns-autoscaler --namespace=kube-system +``` + +다음에 해당하는 줄을 찾는다. + +```yaml +linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}' +``` + +필요에 따라서 해당 필드를 수정한다. +"min" 필드는 최소 DNS 백엔드 수를 나타낸다. 실제 백엔드의 수는 +이 방정식을 사용하여 계산된다. + + replicas = max( ceil( cores × 1/coresPerReplica ) , ceil( nodes × 1/nodesPerReplica ) ) + +`coresPerReplica` 및 `nodesPerReplica` 값은 모두 +부동 소수점이니 주의한다. + +해당 아이디어는 클러스터가 코어가 많은 노드를 사용하는 경우, +`coresPerReplica`의 영향을 더 크게 만들고, 코어 수가 적은 노드를 사용하는 경우 +`nodesPerReplica`의 영향을 더 크게 만드는 것이다. + +그밖에 다른 스케일링 패턴도 지원한다. +[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)를 참고한다. + +## DNS 수평 오토스케일링 비활성화 + +DNS 수평 오토스케일링을 조정하기 위해 몇 가지 옵션이 있다. +사용할 옵션은 조건에 따라 다르다. + +### 옵션 1: dns-autoscaler 디플로이먼트를 레플리카 0개로 축소 + +이 옵션은 모든 상황에서 작동한다. 다음 커맨드를 입력한다. + +```shell +kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system +``` + +출력은 다음과 같다. + + deployment.apps/dns-autoscaler scaled + +레플리카 수가 0인지 확인한다. + +```shell +kubectl get rs --namespace=kube-system +``` + +출력은 DESIRED 및 CURRENT 열에 0으로 보여준다. + + NAME DESIRED CURRENT READY AGE + ... + dns-autoscaler-6b59789fc8 0 0 0 ... + ... + +### 옵션 2: dns-autoscaler 디플로이먼트를 삭제 + +이 옵션은 dns-autoscaler가 자체적으로 제어되는 경우 작동하며, +아무도 이것을 재-생성하지 않음을 의미한다. + +```shell +kubectl delete deployment dns-autoscaler --namespace=kube-system +``` + +출력은 다음과 같다. + + deployment.apps "dns-autoscaler" deleted + +### 옵션 3: 마스터노드에서 dns-autoscaler 매니페스트 파일을 삭제 + +이 옵션은 dns-autoscaler가 (사용 중단되(deprecated)) +[애드온 매니저](https://git.k8s.io/kubernetes/cluster/addons/README.md) +의 제어를 받고 마스터 노드에 쓰기 권한이 있는 경우 작동한다. + +마스터 노드에 로그인하고 해당 매니페스트 파일을 삭제한다. +이 dns-autoscaler의 일반 경로는 다음과 같다. + + /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml + +매니페스트 파일이 삭제된 후, 애드온 매니저는 +dns-autoscaler 디플로이먼트를 삭제한다. + + + + + +## DNS 수평 오토스케일링 작동 방식 이해 + +* cluster-proportional-autoscaler 애플리케이션은 +DNS 서비스와 별도로 배포된다. + +* 오토스케일러 파드는 +클러스터의 노드 및 코어 수에 대해 쿠버네티스 API 서버를 폴링(poll)하는 클라이언트를 실행한다. + +* 의도한 레플리카 수는 주어진 스케일링 파라미터로 계산하고 +예약 가능한 노드 및 코어를 기반으로 DNS 백엔드에 적용한다. + +* 스케일링 파마리터와 데이터 포인트는 컨피그맵을 통해 자동 +오토스케일러에게 제공된다.그리고, 의도한 최근 스케일링 파라미터로 최신 상태가 되도록 +폴링 간격에 따라 파라미터 표를 갱신한다. + +* 오토스케일러 파드를 다시 빌드 또는 재 시작하지 않고도 +스케일링 파라미터를 변경할 수 있다. + +* 오토스케일러는 *linear*와 *ladder* 두 가지 제어 패턴을 지원하는 컨트롤러 +인터페이스를 제공한다. + + + +## {{% heading "whatsnext" %}} + +* [중요한 애드온 파드 스케줄링 보장하기](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)에 대해 읽어본다. +* [cluster-proportional-autoscaler 구현](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) +에 대해 자세히 알아본다. \ No newline at end of file diff --git a/content/ko/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/ko/examples/admin/dns/dns-horizontal-autoscaler.yaml new file mode 100644 index 0000000000..defab8c0c8 --- /dev/null +++ b/content/ko/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -0,0 +1,88 @@ +kind: ServiceAccount +apiVersion: v1 +metadata: + name: kube-dns-autoscaler + namespace: kube-system +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +rules: + - apiGroups: [""] + resources: ["nodes"] + verbs: ["list", "watch"] + - apiGroups: [""] + resources: ["replicationcontrollers/scale"] + verbs: ["get", "update"] + - apiGroups: ["apps"] + resources: ["deployments/scale", "replicasets/scale"] + verbs: ["get", "update"] +# 아래 문제가 해결되면 configmaps 규칙을 제거한다. +# kubernetes-incubator/cluster-proportional-autoscaler#16 + - apiGroups: [""] + resources: ["configmaps"] + verbs: ["get", "create"] +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +subjects: + - kind: ServiceAccount + name: kube-dns-autoscaler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-dns-autoscaler + apiGroup: rbac.authorization.k8s.io + +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: kube-dns-autoscaler + namespace: kube-system + labels: + k8s-app: kube-dns-autoscaler + kubernetes.io/cluster-service: "true" +spec: + selector: + matchLabels: + k8s-app: kube-dns-autoscaler + template: + metadata: + labels: + k8s-app: kube-dns-autoscaler + spec: + priorityClassName: system-cluster-critical + securityContext: + seccompProfile: + type: RuntimeDefault + supplementalGroups: [ 65534 ] + fsGroup: 65534 + nodeSelector: + kubernetes.io/os: linux + containers: + - name: autoscaler + image: registry.k8s.io/cpa/cluster-proportional-autoscaler:1.8.4 + resources: + requests: + cpu: "20m" + memory: "10Mi" + command: + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=kube-dns-autoscaler + # 타겟은 cluster/addons/dns/kube-dns.yaml.base와 동기화된 상태로 유지해야 한다. + + - --target= + # 클러스터가 대규모 노드(많은 코어가 있는)를 사용하는 경우, "coresPerReplica"가 우선시해야 한다. + # 작은 노드를 사용하는 경우, "nodesPerReplica"가 우선시해야 한다. + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}} + - --logtostderr=true + - --v=2 + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + serviceAccountName: kube-dns-autoscaler \ No newline at end of file From 12b4ae25b0c49e6510981207543ee2a5739a5327 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Mon, 27 Mar 2023 14:21:10 +0900 Subject: [PATCH 28/69] [ko] fix operator.md & controller.md in concepts --- content/ko/docs/concepts/architecture/controller.md | 2 +- content/ko/docs/concepts/extend-kubernetes/operator.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 92afd615b6..cf38416206 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -13,7 +13,7 @@ weight: 30 사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를 온도 조절기에 알려준다. -*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 +실제 실내 온도는 *현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 현재 상태를 의도한 상태에 가깝게 만든다. {{< glossary_definition term_id="controller" length="short">}} diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index f59f470f3f..f93d332c4a 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -15,7 +15,7 @@ weight: 30 ## 동기 부여 -_오퍼레이터 패턴_은 서비스 또는 서비스 셋을 관리하는 운영자의 +_오퍼레이터 패턴_ 은 서비스 또는 서비스 셋을 관리하는 운영자의 주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및 서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우 대처 방법에 대해 깊이 알고 있다. From 20b88e92c0d4f1e010aec481027a99fd0935b577 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Tue, 14 Mar 2023 10:29:45 +0900 Subject: [PATCH 29/69] [ko] Update outdated files in `dev-1.26-ko.1` (M8-M9,M127-M133) --- .../concepts/cluster-administration/addons.md | 1 + .../cluster-administration/logging.md | 248 ++++++++++++------ ...-dockershim-and-cri-compatible-runtimes.md | 1 + .../ko/docs/reference/scheduling/_index.md | 2 +- .../ko/docs/reference/scheduling/policies.md | 1 + .../ko/docs/reference/setup-tools/_index.md | 2 +- content/ko/docs/reference/tools/_index.md | 2 +- content/ko/docs/reference/using-api/_index.md | 25 +- .../reference/using-api/client-libraries.md | 3 +- 9 files changed, 184 insertions(+), 101 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 3ba3e35c2a..971b78be79 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -1,6 +1,7 @@ --- title: 애드온 설치 content_type: concept +weight: 120 --- diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index a9ea47332c..93b93eb761 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -9,24 +9,35 @@ weight: 60 -애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. +애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. +로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. +대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. +마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. +컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. -그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. +그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 +완전한 로깅 솔루션으로 충분하지 않다. -예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다. +예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에 +애플리케이션의 로그에 접근하고 싶을 것이다. -클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. +클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 +별도의 스토리지와 라이프사이클을 가져야 한다. +이 개념을 [클러스터-레벨 로깅](#cluster-level-logging-architectures)이라고 한다. + +클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. +쿠버네티스가 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만, +쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. +아래 내용은 로그를 어떻게 처리하고 관리하는지 설명한다. -클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. 쿠버네티스가 -로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만, -쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. +## 파드와 컨테이너 로그 {#basic-logging-in-kubernetes} -## 쿠버네티스의 기본 로깅 +쿠버네티스는 실행중인 파드의 컨테이너에서 출력하는 로그를 감시한다. -이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는 -컨테이너에 대한 `Pod` 명세를 사용한다. +아래 예시는, 초당 한 번씩 표준 출력에 텍스트를 기록하는 +컨테이너를 포함하는 `파드` 매니페스트를 사용한다. {{< codenew file="debug/counter-pod.yaml" >}} @@ -51,10 +62,9 @@ kubectl logs counter 출력은 다음과 같다. ```console -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 -... +0: Fri Apr 1 11:42:23 UTC 2022 +1: Fri Apr 1 11:42:24 UTC 2022 +2: Fri Apr 1 11:42:25 UTC 2022 ``` `kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. @@ -67,72 +77,129 @@ kubectl logs counter -c count 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다. -## 노드 레벨에서의 로깅 +### 노드가 컨테이너 로그를 처리하는 방법 ![노드 레벨 로깅](/images/docs/user-guide/logging/logging-node-level.png) -컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다. -예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다. +컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 런타임이 처리하고 리디렉션 시킨다. +다양한 컨테이너 런타임들은 이를 각자 다른 방법으로 구현하였지만, +kubelet과의 호환성은 _CRI 로깅 포맷_ 으로 표준화되어 있다. -{{< note >}} -도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다. -{{< /note >}} +기본적으로 컨테이너가 재시작하는 경우, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. +파드가 노드에서 축출되면, 해당하는 모든 컨테이너와 로그가 함께 축출된다. -기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다. +kubelet은 쿠버네티스의 특정 API를 통해 사용자들에게 로그를 공개하며, +일반적으로 `kubectl logs`를 통해 접근할 수 있다. -노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여, -로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는 -로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로 -이를 해결하기 위한 솔루션을 설정해야 한다. -예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는, -매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate) -도구가 있다. 애플리케이션의 로그를 자동으로 -로테이션하도록 컨테이너 런타임을 설정할 수도 있다. +### 로그 로테이션 -예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은 -[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해 -자세히 알 수 있다. +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. -kubelet은 이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. -[kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)에 있는 -두 개의 kubelet 파라미터 [`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 -사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다. +kubelet이 로그를 자동으로 로테이트하도록 설정할 수 있다. + +로테이션을 구성해놓으면, kubelet은 컨테이너 로그를 로테이트하고 로깅 경로 구조를 관리한다. +kubelet은 이 정보를 컨테이너 런타임에 전송하고(CRI를 사용), +런타임은 지정된 위치에 컨테이너 로그를 기록한다. + +[kubelet 설정 파일](/docs/tasks/administer-cluster/kubelet-config-file/)을 사용하여 +두 개의 kubelet 파라미터 +[`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 설정 가능하다. +이러한 설정을 통해 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다. 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 -실행하면, 노드의 kubelet이 요청을 처리하고 -로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다. +실행하면, 노드의 kubelet이 요청을 처리하고 로그 파일에서 직접 읽는다. +kubelet은 로그 파일의 내용을 반환한다. + {{< note >}} -만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우, -`kubectl logs` 를 통해 최신 로그 파일의 내용만 -사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가 -로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일) -`kubectl logs` 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다. +`kubectl logs`를 통해서는 +최신 로그만 확인할 수 있다. + +예를 들어, 파드가 40MiB 크기의 로그를 기록했고 kubelet이 10MiB 마다 로그를 로테이트하는 경우 +`kubectl logs`는 최근의 10MiB 데이터만 반환한다. {{< /note >}} -### 시스템 컴포넌트 로그 +## 시스템 컴포넌트 로그 -시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. +시스템 컴포넌트에는 두 가지 유형이 있는데, 컨테이너에서 실행되는 것과 실행 중인 컨테이너와 관련된 것이다. 예를 들면 다음과 같다. -* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다. -* Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다. +* kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다. + kubelet이 컨테이너({{< glossary_tooltip text="파드" term_id="pod" >}}와 그룹화된)를 실행시킨다. +* 쿠버네티스의 스케줄러, 컨트롤러 매니저, API 서버는 + 파드(일반적으로 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}})로 실행된다. + etcd는 컨트롤 플레인에서 실행되며, 대부분의 경우 역시 스태틱 파드로써 실행된다. + 클러스터가 kube-proxy를 사용하는 경우는 `데몬셋(DaemonSet)`으로써 실행된다. -systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다. -systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/log` 디렉터리의 -`.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, -항상 `/var/log` 디렉터리에 기록한다. -시스템 컴포넌트는 [klog](https://github.com/kubernetes/klog) -로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서 -해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다. +### 로그의 위치 {#log-location-node} -컨테이너 로그와 마찬가지로, `/var/log` 디렉터리의 시스템 컴포넌트 로그를 -로테이트해야 한다. `kube-up.sh` 스크립트로 구축한 쿠버네티스 클러스터에서 -로그는 매일 또는 크기가 100MB를 초과하면 -`logrotate` 도구에 의해 로테이트가 되도록 구성된다. +kubelet과 컨테이너 런타임이 로그를 기록하는 방법은, +노드의 운영체제에 따라 다르다. -## 클러스터 레벨 로깅 아키텍처 +{{< tabs name="log_location_node_tabs" >}} +{{% tab name="리눅스" %}} + +systemd를 사용하는 시스템에서는 kubelet과 컨테이너 런타임은 기본적으로 로그를 journald에 작성한다. +`journalctl`을 사용하여 이를 확인할 수 있다. +예를 들어 `journalctl -u kubelet`. + +systemd를 사용하지 않는 시스템에서, kubelet과 컨테이너 런타임은 로그를 `/var/log` 디렉터리의 `.log` 파일에 작성한다. +다른 경로에 로그를 기록하고 싶은 경우에는, `kube-log-runner`를 통해 +간접적으로 kubelet을 실행하여 +kubelet의 로그를 지정한 디렉토리로 리디렉션할 수 있다. + +kubelet을 실행할 때 `--log-dir` 인자를 통해 로그가 저장될 디렉토리를 지정할 수 있다. +그러나 해당 인자는 더 이상 지원되지 않으며(deprecated), kubelet은 항상 컨테이너 런타임으로 하여금 +`/var/log/pods` 아래에 로그를 기록하도록 지시한다. + +`kube-log-runner`에 대한 자세한 정보는 [시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/#klog)를 확인한다. + +{{% /tab %}} +{{% tab name="윈도우" %}} + +kubelet은 기본적으로 `C:\var\logs` 아래에 로그를 기록한다 +(`C:\var\log`가 아님에 주의한다). + +`C:\var\log` 경로가 쿠버네티스에 설정된 기본값이지만, +몇몇 클러스터 배포 도구들은 윈도우 노드의 로그 경로로 `C:\var\log\kubelet`를 사용하기도 한다. + +다른 경로에 로그를 기록하고 싶은 경우에는, `kube-log-runner`를 통해 +간접적으로 kubelet을 실행하여 +kubelet의 로그를 지정한 디렉토리로 리디렉션할 수 있다. + +그러나, kubelet은 항상 컨테이너 런타임으로 하여금 +`C:\var\log\pods` 아래에 로그를 기록하도록 지시한다. + +`kube-log-runner`에 대한 자세한 정보는 [시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/#klog)를 확인한다. +{{% /tab %}} +{{< /tabs >}} + +
    + +파드로 실행되는 쿠버네티스 컴포넌트의 경우, +기본 로깅 메커니즘을 따르지 않고 `/var/log` 아래에 로그를 기록한다 +(즉, 해당 컴포넌트들은 systemd의 journal에 로그를 기록하지 않는다). +쿠버네티스의 저장 메커니즘을 사용하여, 컴포넌트를 실행하는 컨테이너에 영구적으로 사용 가능한 저장 공간을 연결할 수 있다. + +etcd와 etcd의 로그를 기록하는 방식에 대한 자세한 정보는 [etcd 공식 문서](https://etcd.io/docs/)를 확인한다. +다시 언급하자면, 쿠버네티스의 저장 메커니즘을 사용하여 +컴포넌트를 실행하는 컨테이너에 영구적으로 사용 가능한 저장 공간을 연결할 수 있다. + +{{< note >}} +스케줄러와 같은 쿠버네티스 클러스터의 컴포넌트를 배포하여 상위 노드에서 공유된 볼륨에 로그를 기록하는 경우, +해당 로그들이 로테이트되는지 확인하고 관리해야 한다. +**쿠버네티스는 로그 로테이션을 관리하지 않는다**. + +몇몇 로그 로테이션은 운영체제가 자동적으로 구현할 수도 있다. +예를 들어, 컴포넌트를 실행하는 스태틱 파드에 `/var/log` 디렉토리를 공유하여 로그를 기록하면, +노드-레벨 로그 로테이션은 해당 경로의 파일을 +쿠버네티스 외부의 다른 컴포넌트들이 기록한 파일과 동일하게 취급한다. + +몇몇 배포 도구들은 로그 로테이션을 자동화하지만, +나머지 도구들은 이를 사용자의 책임으로 둔다. +{{< /note >}} + +## 클러스터-레벨 로깅 아키텍처 {#cluster-level-logging-architectures} 쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다. @@ -165,7 +232,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo ![스트리밍 컨테이너가 있는 사이드카 컨테이너](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) 사이드카 컨테이너가 자체 `stdout` 및 `stderr` 스트림으로 -쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 +기록하도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다. 각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다. @@ -177,8 +244,8 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo 빌트인 도구를 사용할 수 있다. 예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는 -서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한 -구성 파일은 다음과 같다. +서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. +다음은 파드에 대한 매니페스트이다. {{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} @@ -188,7 +255,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo 컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를 자체 `stdout` 스트림으로 리디렉션할 수 있다. -다음은 사이드카 컨테이너가 두 개인 파드에 대한 구성 파일이다. +다음은 사이드카 컨테이너가 두 개인 파드에 대한 매니페스트이다. {{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}} @@ -202,9 +269,9 @@ kubectl logs counter count-log-1 출력은 다음과 같다. ```console -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 +0: Fri Apr 1 11:42:26 UTC 2022 +1: Fri Apr 1 11:42:27 UTC 2022 +2: Fri Apr 1 11:42:28 UTC 2022 ... ``` @@ -215,27 +282,28 @@ kubectl logs counter count-log-2 출력은 다음과 같다. ```console -Mon Jan 1 00:00:00 UTC 2001 INFO 0 -Mon Jan 1 00:00:01 UTC 2001 INFO 1 -Mon Jan 1 00:00:02 UTC 2001 INFO 2 +Fri Apr 1 11:42:29 UTC 2022 INFO 0 +Fri Apr 1 11:42:30 UTC 2022 INFO 0 +Fri Apr 1 11:42:31 UTC 2022 INFO 0 ... ``` -클러스터에 설치된 노드-레벨 에이전트는 추가 구성없이 +클러스터에 노드-레벨 에이전트를 설치했다면, 에이전트는 추가적인 설정 없이도 자동으로 해당 로그 스트림을 선택한다. 원한다면, 소스 컨테이너에 -따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수 있다. +따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수도 있다. -참고로, CPU 및 메모리 사용량이 낮음에도 불구하고(cpu에 대한 몇 밀리코어의 -요구와 메모리에 대한 몇 메가바이트의 요구), 로그를 파일에 기록한 다음 -`stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에 -쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍 -사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로 -설정하는 것을 추천한다. +CPU 및 메모리 사용량이 낮은(몇 밀리코어 수준의 CPU와 몇 메가바이트 수준의 메모리 요청) 파드라고 할지라도, +로그를 파일에 기록한 다음 `stdout` 으로 스트리밍하는 것은 +노드가 필요로 하는 스토리지 양을 두 배로 늘릴 수 있다. +단일 파일에 로그를 기록하는 애플리케이션이 있는 경우, +일반적으로 스트리밍 사이드카 컨테이너 방식을 구현하는 대신 +`/dev/stdout` 을 대상으로 설정하는 것을 추천한다. -사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는 -로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다. +사이드카 컨테이너를 사용하여 +애플리케이션 자체에서 로테이션할 수 없는 로그 파일을 로테이션할 수도 있다. +이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다. 그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과 -유지 정책을 kubelet에 두는 것이 권장된다. +유지 정책을 kubelet에 두는 것이 더욱 직관적이다. #### 로깅 에이전트가 있는 사이드카 컨테이너 @@ -252,24 +320,30 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2 접근할 수 없다. {{< /note >}} -여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는 -fluentd를 구성하기 위한 [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다. +아래는 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 매니페스트이다. +첫 번째 매니페스트는 fluentd를 구성하는 +[`컨피그맵(ConfigMap)`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다. {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} {{< note >}} -fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](https://docs.fluentd.org/)를 참고한다. +예제 매니페스트에서, 꼭 fluentd가 아니더라도, +애플리케이션 컨테이너 내의 모든 소스에서 로그를 읽어올 수 있는 다른 로깅 에이전트를 사용할 수 있다. {{< /note >}} -두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. +두 번째 매니페스트는 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. 파드는 fluentd가 구성 데이터를 가져올 수 있는 볼륨을 마운트한다. {{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} -이 예시 구성에서, 사용자는 애플리케이션 컨테이너 내의 모든 소스을 읽는 fluentd를 다른 로깅 에이전트로 대체할 수 있다. - ### 애플리케이션에서 직접 로그 노출 ![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png) 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. + +## {{% heading "whatsnext" %}} + +* [쿠버네티스 시스템 로그](/docs/concepts/cluster-administration/system-logs/) 살펴보기. +* [쿠버네티스 시스템 컴포넌트에 대한 추적(trace)](/docs/concepts/cluster-administration/system-traces/) 살펴보기. +* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기. \ No newline at end of file diff --git a/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md b/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md index 3ed3b7cfce..7eef64d390 100644 --- a/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md +++ b/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md @@ -1,6 +1,7 @@ --- title: 도커심 제거 및 CRI 호환 런타임 사용에 대한 기사 content_type: reference +weight: 20 --- 이 문서는 쿠버네티스의 _도커심_ diff --git a/content/ko/docs/reference/scheduling/_index.md b/content/ko/docs/reference/scheduling/_index.md index 7a37a35981..5956f2ae87 100644 --- a/content/ko/docs/reference/scheduling/_index.md +++ b/content/ko/docs/reference/scheduling/_index.md @@ -1,5 +1,5 @@ --- title: 스케줄링 -weight: 70 +weight: 140 toc-hide: true --- diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index 47518285ed..b740b9b3e8 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -3,6 +3,7 @@ title: 스케줄링 정책 content_type: concept sitemap: priority: 0.2 # Scheduling priorities are deprecated +weight: 30 --- diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md index 717b9cb2ac..8cbd2a662f 100644 --- a/content/ko/docs/reference/setup-tools/_index.md +++ b/content/ko/docs/reference/setup-tools/_index.md @@ -1,4 +1,4 @@ --- title: 설치 도구 -weight: 50 +weight: 100 --- diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md index d6188ed7d4..da1b9866f2 100644 --- a/content/ko/docs/reference/tools/_index.md +++ b/content/ko/docs/reference/tools/_index.md @@ -3,7 +3,7 @@ title: 도구 # reviewers: # - janetkuo content_type: concept -weight: 80 +weight: 150 no_list: true --- diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 4716e1081f..691cce639a 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -5,7 +5,7 @@ title: API 개요 # - lavalamp # - jbeda content_type: concept -weight: 10 +weight: 20 no_list: true card: name: 레퍼런스 @@ -50,27 +50,31 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. - 알파(Alpha): - 버전 이름에 `alpha`가 포함된다(예: `v1alpha1`). + - 빌트인 알파 API 버전은 기본적으로 활성화되지 않으며, 활성화하기 위해서는 `kube-apiserver` 설정에 반드시 명시해야 한다. - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. - 기본적으로 비활성화되어 있다. - - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. + - 알파 API에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. - 버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. - 베타(Beta): - 버전 이름에 `beta`가 포함된다(예: `v2beta3`). + - 빌트인 베타 API 버전은 기본적으로 활성화되지 않으며, 활성화하기 위해서는 `kube-apiserver` 설정에 반드시 명시해야 한다. + (**예외사항** 쿠버네티스 1.22 버전 이전의 베타 API들은 기본적으로 활성화되어 있다.) + - 빌트인 베타 API 버전이 더 이상 지원되지 않기까지는 9달 또는 3번의 마이너 릴리스(둘 중 더 긴 것을 기준으로 함)가 걸린다. + 그리고 지원되지 않은 시점에서 제거되기까지는 다시 9달 또는 3번의 마이너 릴리스(둘 중 더 긴 것을 기준으로 함)가 걸린다. - 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. - 기본적으로 활성화되어 있다. - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. - - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 + - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 API 버전에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 - 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 - 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. + 이관할 수 있는 가이드가 제공된다. 다음 베타 또는 안정화 API 버전을 적용하는 것은 + API 오브젝트의 편집 또는 재생성이 필요할 수도 있으며, 그렇게 쉬운 일만은 아닐 것이다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. - 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 - 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 - 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다. + 호환되지 않는 변경 사항이 적용될 수 있다. + 베타 API 버전이 더 이상 지원되지 않는 경우, 후속 베타 또는 안정화 API 버전으로 전환하기 위해서는 + 베타 API 버전을 사용해야 한다. {{< note >}} 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 @@ -79,7 +83,8 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. - 안정화(Stable): - 버전 이름이 `vX`이고 `X` 는 정수다. - - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. + - 안정화된 API 버전은 이후의 모든 쿠버네티스 메이저 버전에서 사용 가능하며, + 현재로써 쿠버네티스 메이저 버전에서 안정화된 API를 제거하려는 계획은 없다. ## API 그룹 diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index f4abf70c60..204e8e1ef0 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -34,7 +34,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) | Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) -| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java/tree/master/examples) | JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) | Perl | [github.com/kubernetes-client/perl/](https://github.com/kubernetes-client/perl/) | [둘러보기](https://github.com/kubernetes-client/perl/tree/master/examples) | Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) @@ -80,5 +80,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | | Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | +| Scala | [github.com/hnaderi/scala-k8s](https://github.com/hnaderi/scala-k8s) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) | From 6a0a44c7ea367382768501205a86a152c273fb27 Mon Sep 17 00:00:00 2001 From: YujinChoi Date: Thu, 23 Mar 2023 22:32:52 +0900 Subject: [PATCH 30/69] [ko] Update outdated files in dev-1.26-ko.1 (M60, M68, M69) --- .../concepts/services-networking/dual-stack.md | 6 +++++- .../topology-aware-hints.md | 18 ++++++++---------- .../services-networking/windows-networking.md | 2 +- 3 files changed, 14 insertions(+), 12 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 5c30d805b1..27661c6fba 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -1,5 +1,9 @@ --- title: IPv4/IPv6 이중 스택 +description: >- + 쿠버네티스는 단일 스택 IPv4 네트워킹, + 단일 스택 IPv6 네트워킹 혹은 두 네트워크 패밀리를 활성화한 + 이중 스택 네트워킹 설정할 수 있도록 해준다. 이 페이지는 이 방법을 설명한다. feature: title: IPv4/IPv6 이중 스택 description: > @@ -10,7 +14,7 @@ content_type: concept # - khenidak # - aramase # - bridgetkromhout -weight: 70 +weight: 90 --- diff --git a/content/ko/docs/concepts/services-networking/topology-aware-hints.md b/content/ko/docs/concepts/services-networking/topology-aware-hints.md index 4f11ff8dd3..d9fa8a71fd 100644 --- a/content/ko/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ko/docs/concepts/services-networking/topology-aware-hints.md @@ -3,7 +3,11 @@ # - robscott title: 토폴로지 인지 힌트 content_type: concept -weight: 45 +weight: 100 +description: >- + _토폴로지 인지 힌트_ 는 트래픽이 발생한 존 내에서 네트워크 트래픽을 유지하도록 처리하는 + 메커니즘을 제공한다. 클러스터의 파드간 동일한 존의 트래픽을 선호하는 것은 + 안전성, 성능(네트워크 지연 및 처리량) 혹은 비용 측면에 도움이 될 수 있다. --- @@ -11,20 +15,14 @@ weight: 45 {{< feature-state for_k8s_version="v1.23" state="beta" >}} -_토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드포인트를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써 +_토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드포인트(endpoint)를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써 토폴로지 인지 라우팅을 가능하게 한다. -이러한 접근은 엔드포인트슬라이스(EndpointSlice) 및 엔드포인트(Endpoint) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며, +이러한 접근은 엔드포인트슬라이스(EndpointSlice) 또는 엔드포인트(Endpoints) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며, 이를 통해 해당 네트워크 엔드포인트로의 트래픽이 근원지에 더 가깝게 라우트될 수 있다. 예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해, 인접성을 고려하여 트래픽을 라우트할 수 있다. -{{< note >}} -"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**. -이 기능을 사용해 보려면, -`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. -{{< /note >}} - ## 동기(motivation) @@ -161,4 +159,4 @@ kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한 ## {{% heading "whatsnext" %}} -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어본다. +* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 따라하기. diff --git a/content/ko/docs/concepts/services-networking/windows-networking.md b/content/ko/docs/concepts/services-networking/windows-networking.md index 400e9c51c1..ba708ec91f 100644 --- a/content/ko/docs/concepts/services-networking/windows-networking.md +++ b/content/ko/docs/concepts/services-networking/windows-networking.md @@ -6,7 +6,7 @@ # - marosset title: 윈도우에서의 네트워킹 content_type: concept -weight: 75 +weight: 110 --- From a9d321f74528cfbeaeb1c27e36af05c08953183b Mon Sep 17 00:00:00 2001 From: mocha-123 Date: Sat, 25 Feb 2023 19:22:42 +0900 Subject: [PATCH 31/69] [ko] Update outdated files in dev-1.26-ko.1 (M70-M81) --- .../concepts/storage/dynamic-provisioning.md | 9 +- .../concepts/storage/persistent-volumes.md | 83 ++++++++-- .../concepts/storage/projected-volumes.md | 18 ++- .../docs/concepts/storage/storage-capacity.md | 2 +- .../docs/concepts/storage/storage-classes.md | 85 +---------- .../docs/concepts/storage/storage-limits.md | 1 + .../storage/volume-health-monitoring.md | 1 + .../concepts/storage/volume-pvc-datasource.md | 2 +- .../storage/volume-snapshot-classes.md | 2 +- .../docs/concepts/storage/volume-snapshots.md | 142 ++++++++++++------ content/ko/docs/concepts/storage/volumes.md | 89 ++++++----- .../docs/concepts/storage/windows-storage.md | 7 +- 12 files changed, 256 insertions(+), 185 deletions(-) diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index e6898ebc66..f4c5fa97df 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -6,7 +6,7 @@ # - msau42 title: 동적 볼륨 프로비저닝 content_type: concept -weight: 40 +weight: 50 --- @@ -19,9 +19,6 @@ weight: 40 스토리지를 사전 프로비저닝 할 필요가 없다. 대신 사용자가 스토리지를 요청하면 자동으로 프로비저닝 한다. - - - ## 배경 @@ -115,8 +112,8 @@ spec: - API 서버에서 [`DefaultStorageClass` 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를 사용하도록 설정한다. -관리자는 `storageclass.kubernetes.io/is-default-class` [어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을 -추가해서 특정 `StorageClass` 를 기본으로 표시할 수 있다. +관리자는 [`storageclass.kubernetes.io/is-default-class` 어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을 +추가하여 특정 `StorageClass` 를 기본으로 표시할 수 있다. 기본 `StorageClass` 가 클러스터에 존재하고 사용자가 `storageClassName` 를 지정하지 않은 `PersistentVolumeClaim` 을 작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index e66e4fe617..dcf730e12d 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -297,18 +297,17 @@ spec: * {{< glossary_tooltip text="csi" term_id="csi" >}} * flexVolume (deprecated) * gcePersistentDisk -* glusterfs * rbd * portworxVolume 스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. -``` yaml +```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: - name: gluster-vol-default -provisioner: kubernetes.io/glusterfs + name: example-vol-default +provisioner: vendor-name.example/magicstorage parameters: resturl: "http://192.168.10.100:8080" restuser: "" @@ -333,7 +332,7 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여 #### CSI 볼륨 확장 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확장을 지원하려면 특정 CSI 드라이버도 필요하다. 자세한 내용은 특정 CSI 드라이버 문서를 참고한다. @@ -438,8 +437,6 @@ PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 (v1.23에서 **사용 중단**) * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk (v1.17에서 **사용 중단**) -* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 - (v1.25에서 **사용 중단**) * [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨 (v1.25에서 **사용 중단**) * [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨 @@ -616,7 +613,6 @@ PV는 `storageClassName` 속성을 * `cephfs` * `cinder` (v1.18에서 **사용 중단됨**) * `gcePersistentDisk` -* `glusterfs` * `iscsi` * `nfs` * `rbd` @@ -745,10 +741,9 @@ AND 조건으로 동작한다. 요청된 클래스와 요청된 레이블이 있 #### 기본 스토리지클래스 할당 소급 적용하기 {#retroactive-default-storageclass-assignment} -{{< feature-state for_k8s_version="v1.25" state="alpha" >}} +{{< feature-state for_k8s_version="v1.26" state="beta" >}} 새로운 PVC를 위한 `storageClassName`을 설정하지 않고 퍼시스턴트볼륨클레임을 생성할 수 있으며, 이는 클러스터에 기본 스토리지클래스가 존재하지 않을 때에도 가능하다. 이 경우, 새로운 PVC는 정의된 대로 생성되며, 해당 PVC의 `storageClassName`은 기본값이 사용 가능해질 때까지 미설정 상태로 남는다. -하지만, [`RetroactiveDefaultStorageClass` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면 쿠버네티스는 다르게 동작하여, 기존에 존재하는 PVC 중 `storageClassName`가 설정되지 않은 PVC는 새로운 기본 스토리지클래스를 사용하도록 갱신된다. 기본 스토리지클래스가 사용 가능해지면, 컨트롤플레인은 `storageClassName`가 없는 PVC를 찾는다. `storageClassName`의 값이 비어있거나 해당 키 자체가 없는 PVC라면, 컨트롤플레인은 해당 PVC의 `storageClassName`가 새로운 기본 스토리지클래스와 일치하도록 설정하여 갱신한다. `storageClassName`가 `""`인 PVC가 있고, 기본 스토리지클래스를 설정한다면, 해당 PVC는 갱신되지 않는다. @@ -953,6 +948,25 @@ kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` 어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외). 기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다. +## 네임스페이스를 교차하는 데이터 소스 +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +쿠버네티스는 네임스페이스를 교차하는 볼륨 데이터 소스를 지원한다. +네임스페이스를 교차하는 볼륨 데이터 소스를 사용하기 위해서는, kube-apiserver, kube-controller-manager에 대해서 `AnyVolumeDataSource`와 `CrossNamespaceVolumeDataSource` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다. +또한, csi-provisioner에 대한 `CrossNamespaceVolumeDataSource` 기능 게이트도 활성화해야 한다. + +`CrossNamespaceVolumeDataSource` 기능 게이트를 활성화하면 dataSourceRef 필드에 네임스페이스를 명시할 수 있다. +{{< note >}} +볼륨 데이터 소스의 네임스페이스를 명시하면, 쿠버네티스는 +참조를 받아들이기 전에 다른 네임스페이스의 레퍼런스그랜트를 확인한다. +레퍼런스그랜트는 `gateway.networking.k8s.io` 확장 API에 속한다. +자세한 정보는 게이트웨이 API 문서의 [레퍼런스그랜트](https://gateway-api.sigs.k8s.io/api-types/referencegrant/)를 참고하라. +즉 이 방법을 사용하려면 우선 게이트웨이 API에서 최소한 레퍼런스그랜트 이상을 사용하여 +쿠버네티스 클러스터를 확장해야 한다는 것을 의미한다. +{{< /note >}} + ## 데이터 소스 참조 `dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다. @@ -970,6 +984,11 @@ kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` * `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는 PVC와 VolumeSnapshot만 포함할 수 있다. +`CrossNamespaceVolumeDataSource` 기능이 활성화되어 있을 때, 추가적인 차이점이 존재한다: + +* `dataSource` 필드는 로컬 오브젝트만을 허용하지만, `dataSourceRef` 필드는 모든 네임스페이스의 오브젝트를 허용한다. +* 네임스페이스가 명시되어 있을 때, `dataSource`와 `dataSourceRef`는 동기화되지 않는다. + 기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은 클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야 할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만 @@ -1010,6 +1029,50 @@ PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이 PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, 볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다. +### 네임스페이스를 교차하는 볼륨 데이터 소스 사용하기 +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +네임스페이스 소유자가 참조를 받아들일 수 있도록 레퍼런스그랜트를 생성한다. +`dataSourceRef` 필드를 사용하여 네임스페이스를 교차하는 볼륨 데이터 소스를 명시해서 파퓰레이트된 볼륨을 정의한다. 이 때, 원천 네임스페이스에 유효한 레퍼런스그랜트를 보유하고 있어야 한다: + + ```yaml + apiVersion: gateway.networking.k8s.io/v1beta1 + kind: ReferenceGrant + metadata: + name: allow-ns1-pvc + namespace: default + spec: + from: + - group: "" + kind: PersistentVolumeClaim + namespace: ns1 + to: + - group: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + ``` + + ```yaml + apiVersion: v1 + kind: PersistentVolumeClaim + metadata: + name: foo-pvc + namespace: ns1 + spec: + storageClassName: example + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + dataSourceRef: + apiGroup: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + namespace: default + volumeMode: Filesystem + ``` + ## 포터블 구성 작성 광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한 diff --git a/content/ko/docs/concepts/storage/projected-volumes.md b/content/ko/docs/concepts/storage/projected-volumes.md index 7fb83d1a2a..62d05dcde8 100644 --- a/content/ko/docs/concepts/storage/projected-volumes.md +++ b/content/ko/docs/concepts/storage/projected-volumes.md @@ -46,7 +46,6 @@ weight: 21 # just after persistent volumes `mode`를 명시적으로 지정할 수 있다. ## 서비스어카운트토큰 프로젝티드 볼륨 {#serviceaccounttoken} -`TokenRequestProjection` 기능이 활성화 된 경우 파드의 지정된 경로에 [서비스어카운트토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)을 주입할 수 있다. @@ -82,6 +81,23 @@ weight: 21 # just after persistent volumes `RunAsUser`가 설정된 리눅스 파드에서는 프로젝티드파일이 컨테이너 사용자 소유권을 포함한 올바른 소유권 집합을 가진다. +파드의 모든 컨테이너의 +[`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)나 +컨테이너 +[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1)의 `runAsUser` 설정이 동일하다면, +kubelet은 `serviceAccountToken` 볼륨의 내용이 해당 사용자의 소유이며, +토큰 파일의 권한 모드는 `0600`로 설정됨을 보장한다. + +{{< note >}} +생성된 후 파드에 추가되는 {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}는 +파드 생성 시 설정된 볼륨 권한을 +변경하지 *않는다*. + +파드 내 그 외의 모든 컨테이너의 `runAsUser`가 동일하여 +파드의 `serviceAccountToken` 볼륨 권한이 `0600`으로 설정되어 있다면, 임시 +컨테이너는 토큰을 읽을 수 있도록 동일한 `runAsUser`를 사용해야 한다. +{{< /note >}} + ### 윈도우 윈도우 파드에서 프로젝티드 볼륨과 파드 `SecurityContext`에 `RunAsUsername`이 설정된 경우, diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index ee0460c129..3f83dc551b 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -7,7 +7,7 @@ # - pohly title: 스토리지 용량 content_type: concept -weight: 70 +weight: 80 --- diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index e7190fd7d0..b97b89b38d 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -6,7 +6,7 @@ # - msau42 title: 스토리지 클래스 content_type: concept -weight: 30 +weight: 40 --- @@ -72,7 +72,6 @@ volumeBindingMode: Immediate | FC | - | - | | FlexVolume | - | - | | GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | -| Glusterfs | ✓ | [Glusterfs](#glusterfs) | | iSCSI | - | - | | NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | @@ -123,7 +122,6 @@ true로 설정된 경우 볼륨 확장을 지원한다. gcePersistentDisk | 1.11 awsElasticBlockStore | 1.11 Cinder | 1.11 -glusterfs | 1.11 rbd | 1.11 Azure File | 1.11 Azure Disk | 1.11 @@ -338,87 +336,6 @@ parameters: [allowedTopologies](#allowed-topologies)로 대체되었다. {{< /note >}} -### Glusterfs - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: slow -provisioner: kubernetes.io/glusterfs -parameters: - resturl: "http://127.0.0.1:8081" - clusterid: "630372ccdc720a92c681fb928f27b53f" - restauthenabled: "true" - restuser: "admin" - secretNamespace: "default" - secretName: "heketi-secret" - gidMin: "40000" - gidMax: "50000" - volumetype: "replicate:3" -``` - -* `resturl`: 필요에 따라 gluster 볼륨을 프로비전하는 Gluster REST 서비스/Heketi - 서비스 url 이다. 일반적인 형식은 `IPaddress:Port` 이어야 하며 이는 GlusterFS - 동적 프로비저너의 필수 파라미터이다. Heketi 서비스가 openshift/kubernetes - 설정에서 라우팅이 가능한 서비스로 노출이 되는 경우 이것은 fqdn이 해석할 수 있는 - Heketi 서비스 url인 `http://heketi-storage-project.cloudapps.mystorage.com` 과 - 유사한 형식을 가질 수 있다. -* `restauthenabled` : REST 서버에 대한 인증을 가능하게 하는 Gluster REST 서비스 - 인증 부울이다. 이 값이 `"true"` 이면, `restuser` 와 `restuserkey` - 또는 `secretNamespace` + `secretName` 을 채워야 한다. 이 옵션은 - 사용 중단이며, `restuser`, `restuserkey`, `secretName` 또는 - `secretNamespace` 중 하나를 지정하면 인증이 활성화된다. -* `restuser` : Gluster REST 서비스/Heketi 사용자로 Gluster Trusted Pool에서 - 볼륨을 생성할 수 있다. -* `restuserkey` : REST 서버에 대한 인증에 사용될 Gluster REST 서비스/Heketi - 사용자의 암호이다. 이 파라미터는 `secretNamespace` + `secretName` 을 위해 - 사용 중단 되었다. -* `secretNamespace`, `secretName` : Gluster REST 서비스와 통신할 때 사용할 - 사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는 - 선택 사항으로 `secretNamespace` 와 `secretName` 을 모두 생략하면 - 빈 암호가 사용된다. 제공된 시크릿은 `"kubernetes.io/glusterfs"` 유형이어야 - 하며, 예를 들어 다음과 같이 생성한다. - - ``` - kubectl create secret generic heketi-secret \ - --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \ - --namespace=default - ``` - - 시크릿의 예시는 - [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml)에서 찾을 수 있다. - -* `clusterid`: `630372ccdc720a92c681fb928f27b53f` 는 볼륨을 프로비저닝할 - 때 Heketi가 사용할 클러스터의 ID이다. 또한, 예시와 같이 클러스터 - ID 목록이 될 수 있다. 예: - `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. 이것은 - 선택적 파라미터이다. -* `gidMin`, `gidMax` : 스토리지클래스에 대한 GID 범위의 최소값과 - 최대값이다. 이 범위( gidMin-gidMax )의 고유한 값(GID)은 동적으로 - 프로비전된 볼륨에 사용된다. 이것은 선택적인 값이다. 지정하지 않으면, - 볼륨은 각각 gidMin과 gidMax의 기본값인 2000-2147483647 - 사이의 값으로 프로비전된다. -* `volumetype` : 볼륨 유형과 파라미터는 이 선택적 값으로 구성할 - 수 있다. 볼륨 유형을 언급하지 않는 경우, 볼륨 유형을 결정하는 것은 - 프로비저너의 책임이다. - - 예를 들어: - * 레플리카 볼륨: `volumetype: replicate:3` 여기서 '3'은 레플리카의 수이다. - * Disperse/EC 볼륨: `volumetype: disperse:4:2` 여기서 '4'는 데이터이고 '2'는 중복 횟수이다. - * Distribute 볼륨: `volumetype: none` - - 사용 가능한 볼륨 유형과 관리 옵션에 대해서는 - [관리 가이드](https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/)를 참조한다. - - 자세한 정보는 - [Heketi 구성 방법](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)을 참조한다. - - 퍼시스턴트 볼륨이 동적으로 프로비전되면 Gluster 플러그인은 - `gluster-dynamic-` 이라는 이름으로 엔드포인트와 - 헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을 - 삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다. - ### NFS ```yaml diff --git a/content/ko/docs/concepts/storage/storage-limits.md b/content/ko/docs/concepts/storage/storage-limits.md index e4a9759d46..326cd84069 100644 --- a/content/ko/docs/concepts/storage/storage-limits.md +++ b/content/ko/docs/concepts/storage/storage-limits.md @@ -6,6 +6,7 @@ # - msau42 title: 노드 별 볼륨 한도 content_type: concept +weight: 90 --- diff --git a/content/ko/docs/concepts/storage/volume-health-monitoring.md b/content/ko/docs/concepts/storage/volume-health-monitoring.md index 75c0a85078..298f545f92 100644 --- a/content/ko/docs/concepts/storage/volume-health-monitoring.md +++ b/content/ko/docs/concepts/storage/volume-health-monitoring.md @@ -6,6 +6,7 @@ # - xing-yang title: 볼륨 헬스 모니터링 content_type: concept +weight: 100 --- diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index f887f6e4a6..239df4c386 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -6,7 +6,7 @@ # - msau42 title: CSI 볼륨 복제하기 content_type: concept -weight: 60 +weight: 70 --- diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 6ff624d65e..e08ffe4381 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ # - yuxiangqian title: 볼륨 스냅샷 클래스 content_type: concept -weight: 41 # just after volume snapshots +weight: 61 # just after volume snapshots --- diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index a47246872e..8d59417149 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -8,70 +8,112 @@ # - yuxiangqian title: 볼륨 스냅샷 content_type: concept -weight: 40 +weight: 60 --- -쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. - - - +쿠버네티스에서 _VolumeSnapshot_ 은 스토리지 시스템 볼륨 스냅샷을 +나타낸다. 이 문서는 이미 쿠버네티스 +[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. ## 소개 -API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 관리자가 볼륨을 프로비전할 때의 방법과 유사하게, `VolumeSnapshotContent` 및 `VolumeSnapshot` API 리소스는 볼륨 스냅샷을 생성하기 위해 제공된다. +API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 +사용자와 관리자를 위해 볼륨을 프로비전할 때 사용되는 것과 유사하게, `VolumeSnapshotContent` +및 `VolumeSnapshot` API 리소스는 사용자와 관리자를 위한 볼륨 스냅샷을 생성하기 위해 +제공된다. -`VolumeSnapshotContent` 는 관리자가 프로버져닝한 클러스터 볼륨에서의 스냅샷이다. 퍼시스턴트볼륨이 클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다. +`VolumeSnapshotContent` 는 관리자가 +프로비져닝한 클러스터 내 볼륨의 스냅샷이다. 퍼시스턴트볼륨이 +클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다. -`VolumeSnapshot` 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는 퍼시스턴트볼륨클레임과 유사하다. +`VolumeSnapshot` 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는 +퍼시스턴트볼륨클레임과 유사하다. -`VolumeSnapshotClass` 을 사용하면 `VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 `PersistentVolumeClaim` 의 `StorageClass` 를 사용하여 표현할 수는 없다. +`VolumeSnapshotClass` 을 사용하면 +`VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 +볼륨에서 가져온 스냅샷마다 다를 수 있으므로 +`PersistentVolumeClaim` 의 동일한 `StorageClass` 를 사용하여 표현할 수는 없다. -볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다. +볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 +표준화된 방법을 제공한다. +예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 +수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다. 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. -* API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다. -* `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다. -* 쿠버네티스 팀은 `VolumeSnapshot` 의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다. -* 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 서버도 있다. 이는 CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다. -* CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다. -* CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다. +- API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` + 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}} + 이다. +- `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다. +- 쿠버네티스 팀은 `VolumeSnapshot` 의 배포 프로세스 일부로써, + 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 + csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. + 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 + `VolumeSnapshotContent` 오브젝트의 생성 및 삭제에 대한 책임을 진다. + 사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 + CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다. +- 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 + 서버도 있다. 이는 + CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 + 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다. +- CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. + 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 + csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다. +- CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다. ## 볼륨 스냅샷 및 볼륨 스냅샷 컨텐츠의 라이프사이클 -`VolumeSnapshotContents` 은 클러스터 리소스이다. `VolumeSnapshots` 은 이러한 리소스의 요청이다. `VolumeSnapshotContents` 과 `VolumeSnapshots`의 상호 작용은 다음과 같은 라이프사이클을 따른다. +`VolumeSnapshotContents` 은 클러스터 리소스이다. `VolumeSnapshots` 은 +이러한 리소스의 요청이다. `VolumeSnapshotContents` 과 `VolumeSnapshots`의 상호 작용은 +다음과 같은 라이프사이클을 따른다. ### 프로비저닝 볼륨 스냅샷 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: . #### 사전 프로비전 {#static} -클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다. + +클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 +클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. +이것은 쿠버네티스 API에 있고 사용 가능하다. #### 동적 -사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. + +사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 +가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)는 +스냅샷 실행 시 스토리지 제공자의 특정 파라미터를 명세한다. ### 바인딩 -스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 `VolumeSnapshot` 오브젝트와 적절한 `VolumeSnapshotContent` 오브젝트와의 바인딩을 처리한다. 바인딩은 1:1 매핑이다. +스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 `VolumeSnapshot` 오브젝트와 적절한 +`VolumeSnapshotContent` 오브젝트와의 바인딩을 처리한다. +바인딩은 1:1 매핑이다. -사전 프로비저닝된 경우, 볼륨스냅샷은 볼륨스냅샷컨텐츠 오브젝트 생성이 요청될 때까지 바인드되지 않은 상태로 유지된다. +사전 프로비저닝된 경우, 볼륨스냅샷은 요청된 볼륨스냅샷컨텐츠 오브젝트가 생성될 때까지 +바인드되지 않은 상태로 유지된다. ### 스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임 이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}} -API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). +API 오브젝트가 시스템에서 지워지지 않게 하는 것이다 +(데이터 손실이 발생할 수 있기 때문에). -퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. +퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 +사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 +삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, +퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. ### 삭제 -삭제는 `VolumeSnapshot` 를 삭제 시 트리거로 `DeletionPolicy` 가 실행된다. `DeletionPolicy` 가 `Delete` 라면, 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제될 것이다. `DeletionPolicy` 이 `Retain` 이라면, 기본 스트리지 스냅샷과 `VolumeSnapshotContent` 둘 다 유지된다. +`VolumeSnapshot` 를 삭제하면 삭제 과정이 트리거되고, `DeletionPolicy` 가 +이어서 실행된다. `DeletionPolicy` 가 `Delete` 라면, 기본 스토리지 스냅샷이 +`VolumeSnapshotContent` 오브젝트와 함께 삭제될 것이다. `DeletionPolicy` 가 +`Retain` 이라면, 기본 스트리지 스냅샷과 `VolumeSnapshotContent` 둘 다 유지된다. ## 볼륨 스냅샷 @@ -88,13 +130,17 @@ spec: persistentVolumeClaimName: pvc-test ``` -`persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다. +`persistentVolumeClaimName` 은 스냅샷을 위한 퍼시스턴트볼륨클레임 데이터 소스의 +이름이다. 이 필드는 동적 프로비저닝 스냅샷이 필요하다. 볼륨 스냅샷은 `volumeSnapshotClassName` 속성을 사용하여 [볼륨스냅샷클래스](/ko/docs/concepts/storage/volume-snapshot-classes/)의 이름을 지정하여 -특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 기본 클래스가 사용될 것이다. +특정 클래스를 요청할 수 있다. 아무것도 설정하지 않으면, 사용 가능한 경우 +기본 클래스가 사용될 것이다. -사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다. +사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 +스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 +`volumeSnapshotContentName` 소스 필드가 필요하다. ```yaml apiVersion: snapshot.storage.k8s.io/v1 @@ -108,7 +154,8 @@ spec: ## 볼륨 스냅샷 컨텐츠 -각각의 볼륨스냅샷컨텐츠는 스펙과 상태를 포함한다. 동적 프로비저닝에서는, 스냅샷 공통 컨트롤러는 `VolumeSnapshotContent` 오브젝트를 생성한다. 예시는 다음과 같다. +각각의 볼륨스냅샷컨텐츠는 스펙과 상태를 포함한다. 동적 프로비저닝에서는, +스냅샷 공통 컨트롤러는 `VolumeSnapshotContent` 오브젝트를 생성한다. 예시는 다음과 같다. ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 @@ -128,9 +175,13 @@ spec: uid: 72d9a349-aacd-42d2-a240-d775650d2455 ``` -`volumeHandle` 은 스토리지 백엔드에서 생성되고 볼륨 생성 중에 CSI 드라이버가 반환하는 볼륨의 고유 식별자이다. 이 필드는 스냅샷을 동적 프로비저닝하는 데 필요하다. 이것은 스냅샷의 볼륨 소스를 지정한다. +`volumeHandle` 은 스토리지 백엔드에서 생성되고 +볼륨 생성 중에 CSI 드라이버가 반환하는 볼륨의 고유 식별자이다. 이 필드는 +스냅샷을 동적 프로비저닝하는 데 필요하다. +이것은 스냅샷의 볼륨 소스를 지정한다. -사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 `VolumeSnapshotContent` 오브젝트를 작성해야 한다. +사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 +`VolumeSnapshotContent` 오브젝트를 생성해야 한다. ```yaml apiVersion: snapshot.storage.k8s.io/v1 @@ -148,19 +199,24 @@ spec: namespace: default ``` -`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. `VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 지정한다. +`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 +고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. +`VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 +지정한다. -`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다. -`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다. -소스 볼륨 모드가 명시되어 있지 않으면, +`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다. +`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다. +소스 볼륨 모드가 명시되어 있지 않으면, 쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다. -`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다. `VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우, `volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다. +`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다. +`VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우, +`volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다. ## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode} -클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, -인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이 +클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, +인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이 API에 있는 것이다. 클러스터가 이 기능을 지원하는지 확인하려면, 다음 명령어를 실행한다. @@ -169,13 +225,13 @@ API에 있는 것이다. $ kubectl get crd volumesnapshotcontent -o yaml ``` -사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때 -기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면, -`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에 +사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때 +기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면, +`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에 `snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` 어노테이션을 추가해야 한다. -이전에 프로비전된 스냅샷의 경우에는, -클러스터 관리자가 `Spec.SourceVolumeMode`를 추가해야 한다. +이전에 프로비전된 스냅샷의 경우에는, 클러스터 관리자가 `spec.sourceVolumeMode`를 +추가해야 한다. 이 기능이 활성화된 예시 `VolumeSnapshotContent` 리소스는 다음과 같을 것이다. @@ -199,7 +255,7 @@ spec: ## 스냅샷을 위한 프로비저닝 볼륨 -`PersistentVolumeClaim` 오브젝트의 *dataSource* 필드를 사용하여 +`PersistentVolumeClaim` 오브젝트의 _dataSource_ 필드를 사용하여 스냅샷 데이터로 미리 채워진 새 볼륨을 프로비저닝할 수 있다. 보다 자세한 사항은 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index aa12838fa0..0338e15613 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -172,7 +172,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} `azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) @@ -335,12 +335,20 @@ spec: * 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 컨테이너가 가져오는 파일을 보관 -환경에 따라, `emptyDir` 볼륨은 디스크, SSD 또는 네트워크 스토리지와 -같이 노드를 지원하는 모든 매체에 저장된다. 그러나, `emptyDir.medium` 필드를 -`"Memory"`로 설정하면, 쿠버네티스에 tmpfs(RAM 기반 파일시스템)를 마운트하도록 할 수 있다. -tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고, -작성하는 모든 파일이 컨테이너 메모리 -제한에 포함된다. +`emptyDir.medium` 필드는 `emptyDir` 볼륨이 저장되는 곳을 제어한다. +기본 `emptyDir` 볼륨은 환경에 따라 +디스크, SSD 또는 네트워크 스토리지와 같이 노드를 지원하는 모든 매체에 저장된다. +`emptyDir.medium` 필드를 `"Memory"`로 설정하면, 쿠버네티스는 tmpfs(RAM 기반 파일시스템)를 대신 +마운트한다. tmpfs는 매우 빠르지만, 디스크와 다르게 +노드 재부팅시 tmpfs는 마운트 해제되고, 작성하는 모든 파일이 +컨테이너 메모리 제한에 포함된다. + + +`emptyDir` 볼륨의 용량을 제한하는 기본 medium을 위해, +크기 제한을 명시할 수 있다. 스토리지는 [노드 임시 +스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-스토리지에-대한-요청-및-제한-설정)로부터 할당된다. +만약 해당 공간이 다른 소스(예를 들어, 로그 파일이나 이미지 오버레이)에 의해 +채워져있다면, `emptyDir`는 지정된 제한 이전에 용량을 다 쓰게 될 수 있다. {{< note >}} `SizeMemoryBackedVolumes` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우, @@ -364,7 +372,8 @@ spec: name: cache-volume volumes: - name: cache-volume - emptyDir: {} + emptyDir: + sizeLimit: 500Mi ``` ### fc (파이버 채널) {#fc} @@ -533,24 +542,15 @@ spec: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` +### glusterfs (제거됨) {#glusterfs} -### glusterfs (사용 중단됨) + +- +쿠버네티스 {{< skew currentVersion >}} 는 `glusterfs` 볼륨 타입을 포함하지 않는다. -{{< feature-state for_k8s_version="v1.25" state="deprecated" >}} - -`glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈 -소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를 -제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` -볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 -glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데이터를 -공유할 수 있다. GlusterFS는 여러 작성자가 동시에 -마운트할 수 있다. - -{{< note >}} -사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. -{{< /note >}} - -더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다. +GlusterFS 인-트리 스토리지 드라이버는 쿠버네티스 1.25에서 사용 중단되었고 +v1.26 릴리즈에서 완전히 제거되었다. ### hostPath {#hostpath} @@ -762,11 +762,33 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla 파드 간에 데이터를 공유할 수 있다는 뜻이다. NFS는 여러 작성자가 동시에 마운트할 수 있다. +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: registry.k8s.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /my-nfs-data + name: test-volume + volumes: + - name: test-volume + nfs: + server: my-nfs-server.example.com + path: /my-nfs-volume + readOnly: true +``` + {{< note >}} 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. + +또한 파드 스펙에 NFS 마운트 옵션을 명시할 수 없음을 기억하라. 마운트 옵션을 서버에서 설정하거나, [/etc/nfsmount.conf](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html)를 사용해야 한다. 마운트 옵션을 설정할 수 있게 허용하는 퍼시스턴트볼륨을 통해 NFS 볼륨을 마운트할 수도 있다. {{< /note >}} -더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다. +퍼시스턴트볼륨을 사용하여 NFS 볼륨을 마운트하는 예제는 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다. ### persistentVolumeClaim {#persistentvolumeclaim} @@ -921,20 +943,17 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 #### vSphere CSI 마이그레이션 {#vsphere-csi-migration} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} - -`vsphereVolume` 용 `CSIMigrationvSphere` 기능은 쿠버네티스 v1.25부터 기본적으로 활성화되어 있다. -인-트리 `vspherevolume`의 모든 플러그인 작업은 `CSIMigrationvSphere` 기능 게이트가 비활성화된 경우를 제외하고 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}로 리다이렉트된다. +{{< feature-state for_k8s_version="v1.26" state="stable" >}} +쿠버네티스 {{< skew currentVersion >}}에서, 인-트리 `vsphereVolume` 타입을 위한 모든 작업은 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 리다이렉트된다. [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 -클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 +클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 [인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다. +vSphere CSI 드라이버가 설치되어있지 않다면 볼륨 작업은 인-트리 `vsphereVolume` 타입으로 생성된 PV에서 수행될 수 없다. -쿠버네티스 v1.25 현재, 7.0u2 이하의 vSphere는 -(사용 중단된) 인-트리 vSphere 스토리지 드라이버가 지원되지 않는다. -사용 중단된 드라이버를 계속 사용하거나, 교체된 CSI 드라이버로 -마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다. +vSphere CSI 드라이버로 마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다. v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우, 해당 쿠버네티스 버전의 문서를 참고한다. @@ -1220,7 +1239,7 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 * [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) -### flexVolume (사용 중단됨) {#flexvolume-deprecated} +### flexVolume (사용 중단됨) {#flexvolume} {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} diff --git a/content/ko/docs/concepts/storage/windows-storage.md b/content/ko/docs/concepts/storage/windows-storage.md index 9dae4c3271..f5add4af56 100644 --- a/content/ko/docs/concepts/storage/windows-storage.md +++ b/content/ko/docs/concepts/storage/windows-storage.md @@ -8,6 +8,7 @@ # - aravindhp title: 윈도우 스토리지 content_type: concept +weight: 110 --- @@ -56,9 +57,9 @@ content_type: concept [플러그인](/ko/docs/concepts/storage/volumes/#volume-types) 형태로 제공된다. 윈도우는 다음의 광역 쿠버네티스 볼륨 플러그인 클래스를 지원한다. -* [`FlexVolume 플러그인`](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) - * FlexVolumes은 1.23부터 사용 중단되었음에 유의한다. -* [`CSI 플러그인`](/ko/docs/concepts/storage/volumes/#csi) +* [`FlexVolume` 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume) + * FlexVolume은 1.23부터 사용 중단되었음에 유의한다. +* [`CSI` 플러그인](/ko/docs/concepts/storage/volumes/#csi) ##### 인-트리(In-tree) 볼륨 플러그인 From 41aeff23ce4b3fa726ef0a266f05325d62a1c35f Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Thu, 23 Feb 2023 09:03:32 +0900 Subject: [PATCH 32/69] [ko] Update outdated files in dev-1.26-ko.1 (M112-M125) --- content/ko/docs/concepts/windows/intro.md | 17 ++- .../ko/docs/reference/glossary/container.md | 2 +- .../reference/glossary/ephemeral-container.md | 2 + content/ko/docs/reference/glossary/secret.md | 15 +- .../ko/docs/reference/glossary/static-pod.md | 4 +- .../docs/reference/issues-security/_index.md | 2 +- content/ko/docs/reference/kubectl/_index.md | 127 ++++++++-------- .../ko/docs/reference/kubectl/cheatsheet.md | 13 +- .../ko/docs/reference/kubectl/conventions.md | 1 + .../kubectl/docker-cli-to-kubectl.md | 1 + content/ko/docs/reference/kubectl/jsonpath.md | 1 + content/ko/docs/reference/kubectl/kubectl.md | 11 ++ .../labels-annotations-taints/_index.md | 139 ++++++++++++++---- 13 files changed, 234 insertions(+), 101 deletions(-) diff --git a/content/ko/docs/concepts/windows/intro.md b/content/ko/docs/concepts/windows/intro.md index 42eabf61b6..11b6f297fa 100644 --- a/content/ko/docs/concepts/windows/intro.md +++ b/content/ko/docs/concepts/windows/intro.md @@ -212,7 +212,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * `securityContext.capabilities` - POSIX 기능은 윈도우에서 구현되지 않았다. * `securityContext.privileged` - - 윈도우는 특권을 가진(privileged) 컨테이너를 지원하지 않는다. + 윈도우는 특권을 가진(privileged) 컨테이너를 지원하지 않는다. 대신 [호스트 프로세스 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod/)를 사용한다. * `securityContext.procMount` - 윈도우에는 `/proc` 파일시스템이 없다. * `securityContext.readOnlyRootFilesystem` - @@ -238,11 +238,11 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 다음 목록은 윈도우와 리눅스에서 파드 명세가 어떻게 다르게 동작하는지 기술한다. * `hostIPC` 및 `hostpid` - 호스트 네임스페이스 공유 기능은 윈도우에서 사용할 수 없다. -* `hostNetwork` - 윈도우 운영 체제에서 호스트 네트워크 공유 기능을 지원하지 않는다. +* `hostNetwork` - [하단 참조](#compatibility-v1-pod-spec-containers-hostnetwork) * `dnsPolicy` - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 `dnsPolicy`를 `ClusterFirstWithHostNet`로 설정할 수 없다. 파드는 항상 컨테이너 네트워크와 함께 동작한다. -* `podSecurityContext` (하단 참조) +* `podSecurityContext` [하단 참조](#compatibility-v1-pod-spec-containers-securitycontext) * `shareProcessNamespace` - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 의존한다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다. @@ -261,6 +261,17 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * `mountPropagation` - 마운트 전파(propagation)는 윈도우에서 지원되지 않으므로 이 필드는 활성화할 수 없다. +#### 호스트 네트워크(hostNetwork)의 필드 호환성 {#compatibility-v1-pod-spec-containers-hostnetwork} + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +이제 kubelet은, 윈도우 노드에서 실행되는 파드가 새로운 파드 네트워크 네임스페이스를 생성하는 대신 호스트의 네트워크 네임스페이스를 사용하도록 요청할 수 있다. +이 기능을 활성화하려면 kubelet에 `--feature-gates=WindowsHostNetwork=true`를 전달한다. + +{{< note >}} +이 기능을 지원하는 컨테이너 런타임을 필요로 한다. +{{< /note >}} + #### 파드 시큐리티 컨텍스트의 필드 호환성 {#compatibility-v1-pod-spec-containers-securitycontext} 파드 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)의 모든 필드는 윈도우에서 작동하지 않는다. diff --git a/content/ko/docs/reference/glossary/container.md b/content/ko/docs/reference/glossary/container.md index 9d01041f9e..1bf46e914e 100644 --- a/content/ko/docs/reference/glossary/container.md +++ b/content/ko/docs/reference/glossary/container.md @@ -16,4 +16,4 @@ tags: 컨테이너는 애플리케이션과 기반이 되는 호스트 인프라의 관계를 분리시켜서, 애플리케이션을 다른 클라우드 또는 OS 환경에서도 쉽게 디플로이하고 쉽게 스케일되게 한다. - +컨테이너 내에서 실행되는 애플리케이션을 컨테이너화된 애플리케이션이라고 한다. 이러한 애플리케이션들과 그에 의존하는 파일 및 라이브러리들을 묶어 컨테이너 이미지로 만들어내는 과정을 컨테이너화라고 한다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/ephemeral-container.md b/content/ko/docs/reference/glossary/ephemeral-container.md index 2e43c0ccbe..b38f701ec6 100644 --- a/content/ko/docs/reference/glossary/ephemeral-container.md +++ b/content/ko/docs/reference/glossary/ephemeral-container.md @@ -16,5 +16,7 @@ tags: 문제가 있는 실행 중 파드를 조사하고 싶다면, 파드에 임시 컨테이너를 추가하고 진단을 수행할 수 있다. 임시 컨테이너는 리소스 및 스케줄링에 대한 보장이 제공되지 않으며, 워크로드 자체를 실행하기 위해 임시 컨테이너를 사용해서는 안 된다. +{{< glossary_tooltip text="스태틱 파드(static pod)" term_id="static-pod" >}}는 임시 컨테이너를 지원하지 않는다. + 더 자세한 정보는 파드 API의 [EphemeralContainer](/docs/reference/kubernetes-api/workload-resources/pod-v1/#EphemeralContainer)를 참고한다. diff --git a/content/ko/docs/reference/glossary/secret.md b/content/ko/docs/reference/glossary/secret.md index 69923c2b4e..01937d2574 100644 --- a/content/ko/docs/reference/glossary/secret.md +++ b/content/ko/docs/reference/glossary/secret.md @@ -4,15 +4,24 @@ id: secret date: 2018-04-12 full_link: /ko/docs/concepts/configuration/secret/ short_description: > - 비밀번호, OAuth 토큰 및 ssh 키와 같은 민감한 정보를 저장한다. + 비밀번호, OAuth 토큰 및 SSH 키와 같은 민감한 정보를 저장한다. aka: tags: - core-object - security --- - 비밀번호, OAuth 토큰 및 ssh 키와 같은 민감한 정보를 저장한다. + 비밀번호, OAuth 토큰 및 SSH 키와 같은 민감한 정보를 저장한다. -민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 우발적인 노출 위험을 줄인다. 시크릿 값은 기본적으로 base64 문자열로 인코딩되어 암호화되지 않은 채로 저장되지만, [안전하게 암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)되도록 설정할 수 있다. {{< glossary_tooltip text="파드" term_id="pod" >}}는 볼륨 마운트 내의 파일 형태로 시크릿에 접근하며, 시크릿은 또한 kubelet이 파드를 위해 이미지를 풀링할 때에도 사용될 수 있다. 시크릿은 기밀 데이터를 다루는 용도로 적합하며, [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터를 다루는 용도로 적합하다. +시크릿을 사용하면 민감한 정보가 사용되는 방법을 더 잘 통제할 수 있으며, +실수로 외부에 노출되는 위험도 줄일 수 있다. +시크릿 값은 base64 문자열로 인코딩되며 기본적으로는 평문으로 저장되지만, +[암호화하여 저장](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)하도록 설정할 수도 있다. + +{{< glossary_tooltip text="파드" term_id="pod" >}}는 볼륨을 마운트하거나 혹은 환경 변수를 통하는 등 +다양한 방식으로 시크릿을 참조할 수 있다. +시크릿은 기밀 데이터를 다루는 용도로 적합하며, +[컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 +기밀이 아닌 데이터를 다루는 용도로 적합하다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/static-pod.md b/content/ko/docs/reference/glossary/static-pod.md index b00b9bada6..2155d1f785 100644 --- a/content/ko/docs/reference/glossary/static-pod.md +++ b/content/ko/docs/reference/glossary/static-pod.md @@ -15,4 +15,6 @@ tags: 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}로, -API 서버가 관찰하지 않는다. \ No newline at end of file +API 서버가 관찰하지 않는다. + +스태틱 파드는 {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를 지원하지 않는다. \ No newline at end of file diff --git a/content/ko/docs/reference/issues-security/_index.md b/content/ko/docs/reference/issues-security/_index.md index 12ac2f3759..9fcc7aeba6 100644 --- a/content/ko/docs/reference/issues-security/_index.md +++ b/content/ko/docs/reference/issues-security/_index.md @@ -1,4 +1,4 @@ --- title: 쿠버네티스 이슈와 보안 -weight: 40 +weight: 70 --- diff --git a/content/ko/docs/reference/kubectl/_index.md b/content/ko/docs/reference/kubectl/_index.md index 26890840a1..701c5f86b0 100644 --- a/content/ko/docs/reference/kubectl/_index.md +++ b/content/ko/docs/reference/kubectl/_index.md @@ -1,7 +1,7 @@ --- title: 명령줄 도구 (kubectl) content_type: reference -weight: 60 +weight: 110 no_list: true card: name: reference @@ -101,7 +101,13 @@ kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한 kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다. 이는 클러스터 외부에서 실행되었을 때와는 다른데, kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우 -kubectl은 `default` 네임스페이스에 대해 동작한다. +kubectl 명령어는 클라이언트 구성에서 현재 컨텍스트(current context)에 +설정된 네임스페이스에 대해 동작한다. +kubectl이 동작하는 기본 네임스페이스를 변경하려면 아래의 명령어를 실행한다. + +```shell +kubectl config set-context --current --namespace= +``` ## 명령어 @@ -130,6 +136,7 @@ kubectl은 `default` 네임스페이스에 대해 동작한다. `diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다. `drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다. `edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다. +`events` | `kubectl events` | List events `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다. `explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다. `expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다. @@ -159,66 +166,66 @@ kubectl은 `default` 네임스페이스에 대해 동작한다. 다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. -(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.) +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.25.0 에서의 출력을 기준으로 한다.) -| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND | +| NAME | SHORTNAMES | APIVERSION | NAMESPACED | KIND | |---|---|---|---|---| -| `bindings` | | | true | Binding | -| `componentstatuses` | `cs` | | false | ComponentStatus | -| `configmaps` | `cm` | | true | ConfigMap | -| `endpoints` | `ep` | | true | Endpoints | -| `events` | `ev` | | true | Event | -| `limitranges` | `limits` | | true | LimitRange | -| `namespaces` | `ns` | | false | Namespace | -| `nodes` | `no` | | false | Node | -| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | -| `persistentvolumes` | `pv` | | false | PersistentVolume | -| `pods` | `po` | | true | Pod | -| `podtemplates` | | | true | PodTemplate | -| `replicationcontrollers` | `rc` | | true | ReplicationController | -| `resourcequotas` | `quota` | | true | ResourceQuota | -| `secrets` | | | true | Secret | -| `serviceaccounts` | `sa` | | true | ServiceAccount | -| `services` | `svc` | | true | Service | -| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | -| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | -| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition | -| `apiservices` | | apiregistration.k8s.io | false | APIService | -| `controllerrevisions` | | apps | true | ControllerRevision | -| `daemonsets` | `ds` | apps | true | DaemonSet | -| `deployments` | `deploy` | apps | true | Deployment | -| `replicasets` | `rs` | apps | true | ReplicaSet | -| `statefulsets` | `sts` | apps | true | StatefulSet | -| `tokenreviews` | | authentication.k8s.io | false | TokenReview | -| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | -| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | -| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | -| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | -| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | -| `cronjobs` | `cj` | batch | true | CronJob | -| `jobs` | | batch | true | Job | -| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | -| `leases` | | coordination.k8s.io | true | Lease | -| `endpointslices` | | discovery.k8s.io | true | EndpointSlice | -| `events` | `ev` | events.k8s.io | true | Event | -| `ingresses` | `ing` | extensions | true | Ingress | -| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema | -| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration | -| `ingressclasses` | | networking.k8s.io | false | IngressClass | -| `ingresses` | `ing` | networking.k8s.io | true | Ingress | -| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | -| `runtimeclasses` | | node.k8s.io | false | RuntimeClass | -| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | -| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | -| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | -| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | -| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | -| `roles` | | rbac.authorization.k8s.io | true | Role | -| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | -| `csidrivers` | | storage.k8s.io | false | CSIDriver | -| `csinodes` | | storage.k8s.io | false | CSINode | -| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | -| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | +| `bindings` | | v1 | true | Binding | +| `componentstatuses` | `cs` | v1 | false | ComponentStatus | +| `configmaps` | `cm` | v1 | true | ConfigMap | +| `endpoints` | `ep` | v1 | true | Endpoints | +| `events` | `ev` | v1 | true | Event | +| `limitranges` | `limits` | v1 | true | LimitRange | +| `namespaces` | `ns` | v1 | false | Namespace | +| `nodes` | `no` | v1 | false | Node | +| `persistentvolumeclaims` | `pvc` | v1 | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | v1 | false | PersistentVolume | +| `pods` | `po` | v1 | true | Pod | +| `podtemplates` | | v1 | true | PodTemplate | +| `replicationcontrollers` | `rc` | v1 | true | ReplicationController | +| `resourcequotas` | `quota` | v1 | true | ResourceQuota | +| `secrets` | | v1 | true | Secret | +| `serviceaccounts` | `sa` | v1 | true | ServiceAccount | +| `services` | `svc` | v1 | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io/v1 | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io/v1 | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io/v1 | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io/v1 | false | APIService | +| `controllerrevisions` | | apps/v1 | true | ControllerRevision | +| `daemonsets` | `ds` | apps/v1 | true | DaemonSet | +| `deployments` | `deploy` | apps/v1 | true | Deployment | +| `replicasets` | `rs` | apps/v1 | true | ReplicaSet | +| `statefulsets` | `sts` | apps/v1 | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io/v1 | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io/v1 | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io/v1 | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io/v1 | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io/v1 | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling/v2 | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch/v1 | true | CronJob | +| `jobs` | | batch/v1 | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io/v1 | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io/v1 | true | Lease | +| `endpointslices` | | discovery.k8s.io/v1 | true | EndpointSlice | +| `events` | `ev` | events.k8s.io/v1 | true | Event | +| `flowschemas` | | flowcontrol.apiserver.k8s.io/v1beta2 | false | FlowSchema | +| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io/v1beta2 | false | PriorityLevelConfiguration | +| `ingressclasses` | | networking.k8s.io/v1 | false | IngressClass | +| `ingresses` | `ing` | networking.k8s.io/v1 | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io/v1 | true | NetworkPolicy | +| `runtimeclasses` | | node.k8s.io/v1 | false | RuntimeClass | +| `poddisruptionbudgets` | `pdb` | policy/v1 | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy/v1beta1 | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io/v1 | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io/v1 | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io/v1 | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io/v1 | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io/v1 | false | PriorityClass | +| `csidrivers` | | storage.k8s.io/v1 | false | CSIDriver | +| `csinodes` | | storage.k8s.io/v1 | false | CSINode | +| `csistoragecapacities` | | storage.k8s.io/v1 | true | CSIStorageCapacity | +| `storageclasses` | `sc` | storage.k8s.io/v1 | false | StorageClass | +| `volumeattachments` | | storage.k8s.io/v1 | false | VolumeAttachment | ## 출력 옵션 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index d328b8fbd0..2563b2fab8 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -39,7 +39,7 @@ complete -o default -F __start_kubectl k source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정 echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다. ``` -### --all-namespaces 에 대한 노트 +### `--all-namespaces` 에 대한 노트 `--all-namespaces`를 붙여야 하는 상황이 자주 발생하므로, `--all-namespaces`의 축약형을 알아 두는 것이 좋다. @@ -225,6 +225,9 @@ kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initConta # 타임스탬프로 정렬된 이벤트 목록 조회 kubectl get events --sort-by=.metadata.creationTimestamp +# 모든 Warning 타입 이벤트 조회 +kubectl events --types=Warning + # 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다. kubectl diff -f ./my-manifest.yaml @@ -266,6 +269,7 @@ kubectl expose rc nginx --port=80 --target-port=8000 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - kubectl label pods my-pod new-label=awesome # 레이블 추가 +kubectl label pods my-pod new-label- # 레이블 제거 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 어노테이션 추가 kubectl autoscale deployment foo --min=2 --max=10 # 디플로이먼트 "foo" 오토스케일 ``` @@ -336,9 +340,8 @@ kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout) kubectl run -i --tty busybox --image=busybox:1.28 -- sh # 대화형 셸로 파드를 실행 kubectl run nginx --image=nginx -n mynamespace # mynamespace 네임스페이스에서 nginx 파드 1개 실행 -kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록 ---dry-run=client -o yaml > pod.yaml - +kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml + # nginx 파드에 대한 spec을 생성하고, pod.yaml이라는 파일에 해당 내용을 기록한다. kubectl attach my-pod -i # 실행 중인 컨테이너에 연결 kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달 kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우) @@ -390,7 +393,7 @@ kubectl cluster-info dump # 현재 kubectl cluster-info dump --output-directory=/path/to/cluster-state # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프 # 현재 노드에 존재하고 있는 테인트(taint)들을 확인 -kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect +kubectl get nodes -o='custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect' # 이미 존재하고 있는 key와 effect를 갖는 테인트의 경우, 지정한 값으로 대체 kubectl taint nodes foo dedicated=special-user:NoSchedule diff --git a/content/ko/docs/reference/kubectl/conventions.md b/content/ko/docs/reference/kubectl/conventions.md index 6b0b2dd61b..7ccbb7457e 100644 --- a/content/ko/docs/reference/kubectl/conventions.md +++ b/content/ko/docs/reference/kubectl/conventions.md @@ -3,6 +3,7 @@ title: kubectl 사용 규칙 # reviewers: # - janetkuo content_type: concept +weight: 60 --- diff --git a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md index 74bf780ff1..0dff130aa4 100644 --- a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -4,6 +4,7 @@ content_type: concept # reviewers: # - brendandburns # - thockin +weight: 50 --- diff --git a/content/ko/docs/reference/kubectl/jsonpath.md b/content/ko/docs/reference/kubectl/jsonpath.md index b3ecc4e70b..98fda79fcf 100644 --- a/content/ko/docs/reference/kubectl/jsonpath.md +++ b/content/ko/docs/reference/kubectl/jsonpath.md @@ -1,6 +1,7 @@ --- title: JSONPath 지원 content_type: concept +weight: 40 --- diff --git a/content/ko/docs/reference/kubectl/kubectl.md b/content/ko/docs/reference/kubectl/kubectl.md index 55d83debe2..49df6ff1d3 100644 --- a/content/ko/docs/reference/kubectl/kubectl.md +++ b/content/ko/docs/reference/kubectl/kubectl.md @@ -351,6 +351,16 @@ kubectl [flags] false로 설정하면, 호출된 kubectl 명령(쿠버네티스 버전 v1.22 이상)을 자세히 설명하는 추가 HTTP 헤더를 해제 + + +tr> +KUBECTL_EXPLAIN_OPENAPIV3 + + +`kubectl explain` 호출에 사용 가능한 새로운 OpenAPIv3 데이터 소스를 사용할지 여부를 전환. 쿠버네티스 1.24 이후로, OpenAPIV3 는 기본적으로 활성화 되어있다. + + + @@ -376,6 +386,7 @@ kubectl [flags] * [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - 적용 예정 버전과 라이브 버전 비교 * [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain) - 유지 보수 준비 중 노드 드레인 * [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit) - 서버에서 리소스 편집 +* [kubectl events](/docs/reference/generated/kubectl/kubectl-commands#events) - 이벤트 목록 나열 * [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - 컨테이너에서 커맨드 실행 * [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - 리소스의 문서 * [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - 레플리케이션 컨트롤러, 서비스, 디플로이먼트 또는 파드를 가져와서 새로운 쿠버네티스 서비스로 노출 diff --git a/content/ko/docs/reference/labels-annotations-taints/_index.md b/content/ko/docs/reference/labels-annotations-taints/_index.md index fd517c8fab..bc22bc9545 100644 --- a/content/ko/docs/reference/labels-annotations-taints/_index.md +++ b/content/ko/docs/reference/labels-annotations-taints/_index.md @@ -1,8 +1,8 @@ --- title: 잘 알려진 레이블, 어노테이션, 테인트(Taint) content_type: concept -weight: 20 - +weight: 40 +no_list: true --- @@ -19,7 +19,7 @@ weight: 20 예시: `app.kubernetes.io/component: "database"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) 아키텍처 내의 컴포넌트. @@ -29,7 +29,7 @@ weight: 20 예시: `app.kubernetes.io/created-by: "controller-manager"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) 리소스를 생성한 컨트롤러/사용자. @@ -41,9 +41,9 @@ v1.9부터 이 레이블은 더 이상 사용되지 않는다. 예시: `app.kubernetes.io/instance: "mysql-abcxzy"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) -애플리케이션 인스턴스를 식별하기 위한 고유한 이름. +애플리케이션 인스턴스를 식별하기 위한 고유한 이름. 고유하지 않은 이름을 할당하려면, [app.kubernetes.io/name](#app-kubernetes-io-name)를 사용한다. [추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. @@ -51,7 +51,7 @@ v1.9부터 이 레이블은 더 이상 사용되지 않는다. 예시: `app.kubernetes.io/managed-by: "helm"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) 애플리케이션의 작업을 관리하기 위해 사용되는 도구. @@ -61,7 +61,7 @@ v1.9부터 이 레이블은 더 이상 사용되지 않는다. 예시: `app.kubernetes.io/name: "mysql"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) 애플리케이션의 이름. @@ -71,7 +71,7 @@ v1.9부터 이 레이블은 더 이상 사용되지 않는다. 예시: `app.kubernetes.io/part-of: "wordpress"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) 해당 애플리케이션이 속한 상위 레벨의 애플리케이션 이름. @@ -81,9 +81,14 @@ v1.9부터 이 레이블은 더 이상 사용되지 않는다. 예시: `app.kubernetes.io/version: "5.7.21"` -적용 대상: 모든 오브젝트 +적용 대상: 모든 오브젝트 (일반적으로 [워크로드 리소스](/docs/reference/kubernetes-api/workload-resources/)에서 사용됨) -애플리케이션의 현재 버전(시맨틱 버전, 리비전 해시, 기타 등등). +애플리케이션의 현재 버전. + +일반적으로 다음과 같은 형태의 값들을 포함한다. + +- [시맨틱 버전](https://semver.org/spec/v1.0.0.html) +- [리비전 해시](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#_single_revisions) 깃 소스 코드 [추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. @@ -128,6 +133,20 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블 레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 이 레이블이 유용할 수 있다. +### kubernetes.io/limit-ranger + +예시: `kubernetes.io/limit-ranger: "LimitRanger plugin set: cpu, memory request for container nginx; cpu, memory limit for container nginx"` + +적용 대상: 파드 + +쿠버네티스는 기본적으로 어떠한 리소스 한도도 설정하지 않는다. 명시적으로 한도를 설정하지 않을 경우, +컨테이너는 CPU와 메모리를 무제한으로 사용하게 된다. +네임스페이스에 리밋레인지를 생성함으로써 리소스에 대한 요청이나 한도 기본값을 파드에 설정할 수 있다. +리밋레인지를 정의한 뒤에 배포된 파드들은 이러한 한도가 적용된다. +`kubernetes.io/limit-ranger` 어노테이션은 파드에 대해 리소스 기본값이 +성공적으로 적용되었다고 기록한다. +자세한 내용은 [리밋레인지](/docs/concepts/policy/limit-range)를 확인한다. + ## beta.kubernetes.io/arch (사용 중단됨) 이 레이블은 사용 중단되었다. 대신 `kubernetes.io/arch` 을 사용한다. @@ -173,6 +192,17 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 이 어노테이션의 값은 **true**로 설정되어야만 작동한다. 이 어노테이션은, 해당 서비스어카운트로 동작중인 파드가 그 서비스어카운트의 `secrets` 항목에 명시된 Secret API 오브젝트만을 참조한다는 뜻이다. +### node.kubernetes.io/exclude-from-external-load-balancer + +예시: `node.kubernetes.io/exclude-from-external-load-balancer` + +적용 대상: 노드 + +쿠버네티스는 클러스터에 `ServiceNodeExclusion` 기능 게이트를 자동으로 활성화한다. 해당 기능 게이트가 클러스터에 활성화되어 있으면, +백엔드 서버들로부터 특정 워커 노드를 제외시키도록 레이블을 추가할 수 있다. +다음 명령어는 백엔드 목록에서 워커 노드를 제외시키는 명령어이다. +`kubectl label nodes node.kubernetes.io/exclude-from-external-load-balancers=true` + ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} 예시: `controller.kubernetes.io/pod-deletion-cost=10` @@ -207,7 +237,7 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 실행파일이 CNI의 실행파일 경로(기본적으로 `/opt/cni/bin`) 아래에 포함되어있는지도 확인하자. {{< /note >}} -Example: `kubernetes.io/ingress-bandwidth: 10M` +예시: `kubernetes.io/ingress-bandwidth: 10M` 적용 대상: 파드 @@ -276,6 +306,14 @@ Example: `kubernetes.io/ingress-bandwidth: 10M` 스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서 상세 사항을 확인한다. +### scheduler.alpha.kubernetes.io/node-selector {#schedulerkubernetesnode-selector} + +예시: `scheduler.alpha.kubernetes.io/node-selector: "name-of-node-selector"` + +적용 대상: 네임스페이스 + +[파드-노드 셀렉터(PodNodeSelector)](/docs/reference/access-authn-authz/admission-controllers/#podnodeselector)는 이 어노테이션의 키를 사용하여 네임스페이스의 파드들에 노드 셀렉터를 할당한다. + ## topology.kubernetes.io/region {#topologykubernetesioregion} 예시: @@ -323,7 +361,7 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클 이 어노테이션은 사용 중단되었다. -### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options} +### volume.beta.kubernetes.io/mount-options (사용 중단) {#mount-options} 예시 : `volume.beta.kubernetes.io/mount-options: "ro,soft"` @@ -359,17 +397,22 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo ## kubernetes.io/service-name {#kubernetesioservice-name} -예시: `kubernetes.io/service-name="nginx"` +예시: `kubernetes.io/service-name="my-website"` -적용 대상: 서비스 +적용 대상: 엔드포인트슬라이스(EndpointSlices) -쿠버네티스가 여러 서비스를 구분하기 위해 이 레이블을 사용한다. 현재는 `ELB`(Elastic Load Balancer) 를 위해서만 사용되고 있다. +쿠버네티스는 이 레이블을 사용하여 [엔드포인트슬라이스](/docs/concepts/services-networking/endpoint-slices/)와 +[서비스](/docs/concepts/services-networking/service/)를 결합한다. + +이 레이블은 엔드포인트슬라이스가 지원하는 서비스의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다. +모든 엔드포인트슬라이스는 이 레이블을 +자신과 연결된 서비스의 이름으로 설정해야 한다. ### kubernetes.io/service-account.name 예시: `kubernetes.io/service-account.name: "sa-name"` -Used on: 시크릿(Secret) +적용 대상: 시크릿(Secret) 이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 서비스어카운트의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다. @@ -383,11 +426,25 @@ Used on: 시크릿(Secret) 이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 서비스어카운트의 {{< glossary_tooltip term_id="uid" text="고유 ID">}}를 기록한다. +### kubernetes.io/legacy-token-last-used + +예시: `kubernetes.io/legacy-token-last-used: 2022-10-24` + +적용 대상: 시크릿 + +컨트롤 플레인은 `kubernetes.io/service-account-token` 타입을 갖는 시크릿에 대해서만 이 레이블을 추가한다. +이 레이블의 값은, 클라이언트가 서비스어카운트 토큰을 사용하여 인증한 요청을 +컨트롤 플레인이 마지막으로 확인한 날짜(ISO 8601 형식, UTC 시간대)를 기록한다. + +클러스터가 해당 기능을 얻기 전에 기존의 토큰을 마지막으로 사용한 경우(쿠버네티스 v1.26에 추가됨), +이 레이블은 설정되지 않는다. + + ## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} 예시: `endpointslice.kubernetes.io/managed-by="controller"` -적용 대상: 엔드포인트슬라이스(EndpointSlices) +적용 대상: 엔드포인트슬라이스 이 레이블은 엔드포인트슬라이스(EndpointSlice)를 어떤 컨트롤러나 엔티티가 관리하는지를 나타내기 위해 사용된다. 이 레이블을 사용함으로써 한 클러스터 내에서 여러 엔드포인트슬라이스 오브젝트가 각각 다른 컨트롤러나 엔티티에 의해 관리될 수 있다. @@ -407,7 +464,7 @@ Used on: 시크릿(Secret) kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다. -## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type} +## experimental.windows.kubernetes.io/isolation-type (사용 중단) {#experimental-windows-kubernetes-io-isolation-type} 예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"` @@ -474,19 +531,37 @@ kube-controller-manager의 잡(Job) 컨트롤러는 적용 대상: 엔드포인트(Endpoints) -v1.22 이상의 쿠버네티스 클러스터에서, 한 엔드포인트(Endpoints) 리소스가 관리하고 있는 엔드포인트의 수가 1000개 이상이면 엔드포인트 컨트롤러가 해당 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 해당 엔드포인트 리소스가 용량 초과 되었으며 엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다. +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은, 연결된 {{< glossary_tooltip text="서비스" term_id="service" >}}에 1000개 이상의 엔드포인트가 있는 경우, 이 어노테이션을 [엔드포인트](/docs/concepts/services-networking/service/#endpoints) 오브젝트에 추가한다. 이 어노테이션은 엔드포인트의 용량이 초과되었거나 엔드포인트의 수가 1000개로 잘렸음을 나타낸다. -## batch.kubernetes.io/job-tracking +백엔드 엔드포인트의 수가 1000개 미만이면, 컨트롤 플레인은 이 어노테이션을 제거한다. + +### batch.kubernetes.io/job-tracking (사용 중단) {#batch-kubernetes-io-job-tracking} 예시: `batch.kubernetes.io/job-tracking: ""` 적용 대상: 잡 -잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers) -중임을 나타낸다. -어노테이션을 수동으로 추가하거나 제거하지 **않는다**. +잡에 이 어노테이션이 있는 경우, 컨트롤 플레인이 +[파이널라이저(finalizer)를 이용하여 잡 상태를 추적](/ko/docs/concepts/workloads/controllers/job/#종료자-finalizers-를-이용한-잡-추적)하고 있음을 나타낸다. +컨트롤 플레인은 이 어노테이션을 사용하여, 아직 기능이 개발 중인 동안 +파이널라이저를 사용하여 잡을 추적하도록 안전하게 전환한다. +이 어노테이션을 수동으로 추가하거나 제거해서는 **안 된다**. -## scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated) {#scheduleralphakubernetesio-preferavoidpods} +{{< note >}} +쿠버네티스 1.26 부터, 이 어노테이션은 사용되지 않는다. +쿠버네티스 1.27 과 그 이상의 버전들은 이 어노테이션을 무시할 것이며, +항상 파이널라이저를 사용하여 잡을 추적할 것이다.. +{{< /note >}} + +### scheduler.alpha.kubernetes.io/defaultTolerations {#scheduleralphakubernetesio-defaulttolerations} + +예시: `scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Equal", "value": "value1", "effect": "NoSchedule", "key": "dedicated-node"}]'` + +적용 대상: 네임스페이스 + +이 어노테이션은 [PodTolerationRestriction](/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction) 어드미션 컨트롤러가 활성화되어 있어야 한다. 어노테이션의 키는 네임스페이스에 톨러레이션(toleration)을 할당하는 것을 허용하며, 해당 네임스페이스에 생성되는 모든 파드들은 이 톨러레이션이 부여된다. + +## scheduler.alpha.kubernetes.io/preferAvoidPods (사용 중단) {#scheduleralphakubernetesio-preferavoidpods} 적용 대상: 노드 @@ -730,7 +805,7 @@ etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위 ### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint -예시: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https//172.17.0.18:6443` +예시: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443` 적용 대상: 파드 @@ -752,10 +827,20 @@ etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위 kubeadm이 관리하는 컨트롤 플레인 노드에 적용되는 레이블. -### node-role.kubernetes.io/control-plane +### node-role.kubernetes.io/control-plane {#node-role-kubernetes-io-control-plane-taint} 예시: `node-role.kubernetes.io/control-plane:NoSchedule` 적용 대상: 노드 중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트. + +### node-role.kubernetes.io/master (사용 중단) {#node-role-kubernetes-io-master-taint} + +적용 대상: Node + +예시: `node-role.kubernetes.io/master:NoSchedule` + +이전 버전에서 kubeadm이 컨트롤 플레인에 중요한 워크로드만 스케줄링하기 위해 적용했던 테인트. +[`node-role.kubernetes.io/control-plane`](#node-role-kubernetes-io-control-plane-taint)로 대체되었다. +kubeadm은 더 이상 해당 테인트를 설정하거나 사용하지 않는다. From 008ff42253d4667304ada7ce611370c22cfa70f8 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Fri, 7 Apr 2023 22:06:22 +0900 Subject: [PATCH 33/69] [ko] translate pod-scheduling-readiness.md into Korean --- .../pod-scheduling-readiness.md | 109 ++++++++++++++++++ .../pods/pod-with-scheduling-gates.yaml | 11 ++ .../pods/pod-without-scheduling-gates.yaml | 8 ++ 3 files changed, 128 insertions(+) create mode 100644 content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md create mode 100644 content/ko/examples/pods/pod-with-scheduling-gates.yaml create mode 100644 content/ko/examples/pods/pod-without-scheduling-gates.yaml diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md b/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md new file mode 100644 index 0000000000..78472fa483 --- /dev/null +++ b/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md @@ -0,0 +1,109 @@ +--- +title: 파드 스케줄링 준비성(readiness) +content_type: concept +weight: 40 +--- + + + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +파드는 생성되면 스케줄링 될 준비가 된 것으로 간주된다. 쿠버네티스 스케줄러는 +모든 Pending 중인 파드를 배치할 노드를 찾기 위한 철저한 조사 과정을 수행한다. 그러나 일부 파드는 +오랜 기간 동안 "필수 리소스 누락" 상태에 머물 수 있다. +이러한 파드는 실제로 스케줄러(그리고 클러스터 오토스케일러와 같은 다운스트림 통합자) +불필요한 방식으로 작동하게 만들 수 있다. + +파드의 `.spec.schedulingGates`를 지정하거나 제거함으로써, +파드가 스케줄링 될 준비가 되는 시기를 제어할 수 있다. + + + +## 파드 스케줄링게이트(schedulingGates) 구성하기 + +`스케줄링게이트(schedulingGates)` 필드는 문자열 목록을 포함하며, 각 문자열 리터럴은 +파드가 스케줄링 가능한 것으로 간주되기 전에 충족해야 하는 기준으로 인식된다. 이 필드는 +파드가 생성될 때만 초기화할 수 있다(클라이언트에 의해 생성되거나, 어드미션 중에 변경될 때). +생성 후 각 스케줄링게이트는 임의의 순서로 제거될 수 있지만, 새로운 스케줄링게이트의 추가는 허용되지 않는다. + +{{}} +stateDiagram-v2 + s1: 파드 생성 + s2: 파드 스케줄링 게이트됨 + s3: 파드 스케줄링 준비됨 + s4: 파드 실행 + if: 스케줄링 게이트가 비어 있는가? + [*] --> s1 + s1 --> if + s2 --> if: 스케줄링 게이트 제거됨 + if --> s2: 아니오 + if --> s3: 네 + s3 --> s4 + s4 --> [*] +{{< /mermaid >}} + +## 사용 예시 + +파드가 스케줄링 될 준비가 되지 않았다고 표시하려면, 다음과 같이 하나 이상의 스케줄링 게이트를 생성하여 표시할 수 있다. + +{{< codenew file="pods/pod-with-scheduling-gates.yaml" >}} + +파드가 생성된 후에는 다음 명령을 사용하여 상태를 확인할 수 있다. + +```bash +kubectl get pod test-pod +``` + +출력은 파드가 `SchedulingGated` 상태임을 보여준다. + +```none +NAME READY STATUS RESTARTS AGE +test-pod 0/1 SchedulingGated 0 7s +``` + +다음 명령을 실행하여 `schedulingGates` 필드를 확인할 수도 있다. + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}' +``` + +출력은 다음과 같다. + +```none +[{"name":"foo"},{"name":"bar"}] +``` + +스케줄러에게 이 파드가 스케줄링 될 준비가 되었음을 알리기 위해, 수정된 매니페스트를 다시 적용하여 +`schedulingGates`를 완전히 제거할 수 있다. + +{{< codenew file="pods/pod-without-scheduling-gates.yaml" >}} + +`schedulingGates`가 지워졌는지 확인하려면 다음 명령을 실행하여 확인할 수 있다. + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}' +``` + +출력은 비어 있을 것이다. 그리고 다음 명령을 실행하여 최신 상태를 확인할 수 있다. + +```bash +kubectl get pod test-pod -o wide +``` + +test-pod가 CPU/메모리 리소스를 요청하지 않았기 때문에, 이 파드의 상태는 이전의 `SchedulingGated`에서 +`Running`으로 전환됐을 것이다. + +```none +NAME READY STATUS RESTARTS AGE IP NODE +test-pod 1/1 Running 0 15s 10.0.0.4 node-2 +``` + +## 가시성(Observability) + +스케줄링을 시도했지만 스케줄링할 수 없다고 클레임되거나 스케줄링할 준비가 되지 않은 것으로 명시적으로 표시된 파드를 +구분하기 위해 `scheduler_pending_pods` 메트릭은 `”gated"`라는 새로운 레이블과 함께 제공된다. +`scheduler_pending_pods{queue="gated"}`를 사용하여 메트릭 결과를 확인할 수 있다. + +## {{% heading "whatsnext" %}} + +* 자세한 내용은 [PodSchedulingReadiness KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3521-pod-scheduling-readiness)를 참고한다. diff --git a/content/ko/examples/pods/pod-with-scheduling-gates.yaml b/content/ko/examples/pods/pod-with-scheduling-gates.yaml new file mode 100644 index 0000000000..b0b012fb72 --- /dev/null +++ b/content/ko/examples/pods/pod-with-scheduling-gates.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + schedulingGates: + - name: foo + - name: bar + containers: + - name: pause + image: registry.k8s.io/pause:3.6 diff --git a/content/ko/examples/pods/pod-without-scheduling-gates.yaml b/content/ko/examples/pods/pod-without-scheduling-gates.yaml new file mode 100644 index 0000000000..5638b6e97a --- /dev/null +++ b/content/ko/examples/pods/pod-without-scheduling-gates.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + containers: + - name: pause + image: registry.k8s.io/pause:3.6 From 32e334d6de27d470560f2e83a5dbd99b9e9b2ae9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=9C=B1=E6=AD=A3=E6=B5=A9=2CZhu=20Zhenghao?= Date: Wed, 5 Apr 2023 17:00:45 +0800 Subject: [PATCH 34/69] [ko]update link of text/template --- .../list-all-running-container-images.md | 4 ++-- .../debug/debug-application/determine-reason-pod-failure.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md index a6f4f086d2..6b066893d0 100644 --- a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -94,7 +94,7 @@ kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers ## jsonpath 대신 Go 템플릿을 사용하여 컨테이너 이미지 목록 보기 -jsonpath의 대안으로 Kubectl은 [Go 템플릿](https://golang.org/pkg/text/template/)을 지원한다. +jsonpath의 대안으로 Kubectl은 [Go 템플릿](https://pkg.go.dev/text/template)을 지원한다. 다음과 같이 결과값의 서식을 지정할 수 있다. ```shell @@ -106,4 +106,4 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r ### 참조 * [Jsonpath](/ko/docs/reference/kubectl/jsonpath/) 참조 -* [Go 템플릿](https://golang.org/pkg/text/template/) 참조 +* [Go 템플릿](https://pkg.go.dev/text/template) 참조 diff --git a/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md index 0ca469e212..0ab055bc71 100644 --- a/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md @@ -129,4 +129,4 @@ spec: * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 에 있는 `terminationMessagePath` 에 대해 읽어보기. * [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기. -* [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기. +* [Go 템플릿](https://pkg.go.dev/text/template)에 대해 배워보기. From 7b4479c0336f68e1d6c540a98e0135ac241fdbe9 Mon Sep 17 00:00:00 2001 From: dewble Date: Fri, 14 Apr 2023 22:53:18 +0900 Subject: [PATCH 35/69] Translate docs/tasks/administer-cluster/kubelet-config-file into Korean Signed-off-by: dewble --- .../administer-cluster/kubelet-config-file.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 content/ko/docs/tasks/administer-cluster/kubelet-config-file.md diff --git a/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md b/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md new file mode 100644 index 0000000000..e1b0581496 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md @@ -0,0 +1,74 @@ +--- +reviewers: +# - mtaufen +# - dawnchen +title: 구성 파일을 통해 Kubelet 파라미터 설정하기 +content_type: task +--- + + + +커맨드 라인 플래그 대신 온디스크 구성 파일을 통해 +Kubelet의 구성 매개변수 하위 집합을 설정할 수 있다. + +구성 파일을 통해 매개변수를 제공하는 것은 +노드 배포 및 구성 관리를 간소화하기 때문에 권장되는 접근 방식이다. + + + +## 구성 파일 만들기 + +파일을 통해 구성할 수 있는 +Kubelet 구성의 하위 집합은 +[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) +에 의해 정의된다. + +구성 파일은 이 구조체의 매개 변수를 반드시 JSON 또는 YAML로 표현한 파일이어야 한다. +Kubelet에 파일에 읽기 권한이 있는지 확인한다. + +다음은 이 파일의 모습에 대한 예입니다. +``` +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +address: "192.168.0.8", +port: 20250, +serializeImagePulls: false, +evictionHard: + memory.available: "200Mi" +``` + +이 예제에서, Kubelet은 IP 주소 192.168.0.8과 20250 포트에서 동작하고, 이미지를 병렬로 가져오고, +사용 가능 메모리가 200Mi 아래로 떨어지면 파드를 축출하도록 구성되어 있다. +플래그에 의해 재정의되지 않는한, 다른 모든 Kubelet 구성은 기본값으로 유지된다. +구성 파일과 동일한 값을 대상으로 하는 커맨드 라인 플래그는 해당 값을 재정의 한다. + +## 구성 파일을 통해 구성된 Kubelet 프로세스 시작하기 + +{{< note >}} +kubeadm을 사용하여 클러스터를 초기화하는 경우 `kubeadmin init`으로 클러스터를 생성하는 동안 kubelete-config를 사용해야 한다. +자세한 내용은 [kubeadm을 사용하여 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/)를 참고한다. +{{< /note >}} + +Kubelet의 구성 파일 경로로 설정된 `--config` 플래그를 사용하여 Kubelet을 시작하면 +Kubelet이 이 파일에서 구성을 불러온다. + +구성 파일과 동일한 값을 대상으로 하는 커맨드 라인 플래그는 해당 값을 재정의한다는 점을 유의한다. +이렇게 하면 커맨드 라인 API와의 이전 버전과의 호환성을 보장할 수 있다. + +Kubelet 구성 파일의 상대 파일 경로는 +Kubelet 구성 파일의 위치를 기준으로 확인되는 반면, 커맨드 라인 플래그의 상대 경로는 +Kubelet의 현재 작업 디렉터리를 기준으로 확인된다는 점에 유의한다. + +일부 기본값은 커맨드 라인 플래그와 Kubelet 구성 파일 간에 다르다는 점에 유의한다. +`--config`가 제공되고 명령줄을 통해 값을 지정하지 않은 경우, +`KubeletConfiguration` 버전의 기본값이 적용된다. +위 예제의 버전은 `kubelet.config.k8s.io/v1beta1`이다. + + + +## {{% heading "whatsnext" %}} + +- Kubelet 구성에 대한 자세한 내용은 + [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) + 를 참고한다. + From 9911446ad6f04fc1f8648038b757d11d0bf49922 Mon Sep 17 00:00:00 2001 From: dewble Date: Sat, 15 Apr 2023 01:05:04 +0900 Subject: [PATCH 36/69] Translate docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes into Korean Signed-off-by: dewble --- .../kubeadm/upgrading-linux-nodes.md | 100 ++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md new file mode 100644 index 0000000000..33c4c017db --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md @@ -0,0 +1,100 @@ +--- +title: 리눅스 노드 업그레이드 +content_type: task +weight: 100 +--- + + + +이 페이지는 kubeadm으로 생성된 리눅스 노드를 업그레이드하는 방법을 설명한다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* [남은 kubeadm 클러스터를 업그레이드하는 프로세스](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)에 +익숙해져야 한다. +리눅스 노드를 업그레이드하기 전에 컨트롤 플레인 노드를 업그레이드해야 한다. + + + +## 워커 노드 업그레이드 + +### kubeadm 업그레이드 + + kubeadm 업그레이드. + + {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubeadm + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} + +### "kubeadm upgrade" 호출 + +- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다. + + ```shell + sudo kubeadm upgrade node + ``` + +### 노드 드레인 + +- 노드를 스케줄 불가능한 것으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. + + ```shell + # replace with the name of your node you are draining + kubectl drain --ignore-daemonsets + ``` + +### kubelet과 kubectl 업그레이드 + +- kubelet과 kubectl 업그레이드. + + {{< tabs name="k8s_kubelet_and_kubectl" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubelet kubectl + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} +
    + +- kubelet 재시작 + + ```shell + sudo systemctl daemon-reload + sudo systemctl restart kubelet + ``` + +### 노드에 적용된 cordon 해제 + +- 스케줄 가능으로 표시하여 노드를 다시 온라인으로 가져온다. + + ```shell + # replace with the name of your node + kubectl uncordon + ``` + + ## {{% heading "whatsnext" %}} + +* [윈도우 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes/)하는 방법. \ No newline at end of file From eda4f1d53356d8f4de48a70bcdc6e3c1dc5641b6 Mon Sep 17 00:00:00 2001 From: Yoon Seo-Yul Date: Sun, 26 Mar 2023 01:12:15 +0900 Subject: [PATCH 37/69] [ko] Update outdated files dev-1.26-ko.1 (M143 - M148) Apply suggestions from code review Co-authored-by: Sanghong Kim <58922834+bconfiden2@users.noreply.github.com> --- .../configure-access-multiple-clusters.md | 59 +++++++++++++------ .../create-external-load-balancer.md | 2 +- .../list-all-running-container-images.md | 13 ---- .../service-access-application-cluster.md | 49 ++++++++------- .../administer-cluster/access-cluster-api.md | 1 + .../tasks/administer-cluster/certificates.md | 8 +-- 6 files changed, 69 insertions(+), 63 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index d42fd1d96e..50c1036dc2 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -22,7 +22,8 @@ card: {{< warning >}} -신뢰할 수 있는 소스의 kubeconfig 파일만 사용해야 한다. 특수 제작된 kubeconfig 파일은 악성코드를 실행하거나 파일을 노출시킬 수 있다. +신뢰할 수 있는 소스의 kubeconfig 파일만 사용해야 한다. +특수 제작된 kubeconfig 파일은 악성코드를 실행하거나 파일을 노출시킬 수 있다. 신뢰할 수 없는 kubeconfig 파일을 꼭 사용해야 한다면, 셸 스크립트를 사용하는 경우처럼 신중한 검사가 선행되어야 한다. {{< /warning>}} @@ -40,12 +41,12 @@ card: ## 클러스터, 사용자, 컨텍스트 정의 -당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. +당신이 개발 작업을 위한 클러스터와 테스트 작업을 위한 클러스터를 가지고 있다고 가정해보자. `development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. -`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 +`test` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, -scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다. +test 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다. `config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에 다음 내용을 가진 `config-demo`라는 파일을 생성한다. @@ -59,7 +60,7 @@ clusters: - cluster: name: development - cluster: - name: scratch + name: test users: - name: developer @@ -71,7 +72,7 @@ contexts: - context: name: dev-storage - context: - name: exp-scratch + name: exp-test ``` 구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 @@ -82,11 +83,15 @@ contexts: ```shell kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file -kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify +kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify ``` 사용자의 세부사항들을 구성 파일에 추가한다. +{{< caution >}} +쿠버네티스 클라이언트 구성에 암호를 저장하는 것은 위험하다. 자격 증명 플러그인을 사용하여 별도로 저장하는 것이 더 나은 대안이다. [client-go 자격증명 플러그인](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)을 참고한다. +{{< /caution >}} + ```shell kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password @@ -103,7 +108,7 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username= ```shell kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer -kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter +kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter ``` `config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 @@ -125,7 +130,7 @@ clusters: - cluster: insecure-skip-tls-verify: true server: https://5.6.7.8 - name: scratch + name: test contexts: - context: cluster: development @@ -138,10 +143,10 @@ contexts: user: developer name: dev-storage - context: - cluster: scratch + cluster: test namespace: default user: experimenter - name: exp-scratch + name: exp-test current-context: "" kind: Config preferences: {} @@ -152,6 +157,11 @@ users: client-key: fake-key-file - name: experimenter user: + # 문서 참고 사항 (이 설명은 명령 출력의 일부가 아니다.) + # 쿠버네티스 클라이언트 구성에 암호를 저장하는 것은 위험하다. + # 자격 증명 플러그인을 사용하여 + # 자격 증명을 별도로 저장하는 것이 더 나은 대안이다. + # 다음을 참고하자. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins password: some-password username: exp ``` @@ -210,19 +220,19 @@ users: client-key: fake-key-file ``` -이제 당신이 잠시 scratch 클러스터에서 작업하려고 한다고 가정해보자. +이제 당신이 잠시 test 클러스터에서 작업하려고 한다고 가정해보자. -현재 컨텍스트를 `exp-scratch`로 변경한다. +현재 컨텍스트를 `exp-test`로 변경한다. ```shell -kubectl config --kubeconfig=config-demo use-context exp-scratch +kubectl config --kubeconfig=config-demo use-context exp-test ``` -이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 -default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 +이제 당신이 실행하는 모든 `kubectl` 커맨드는 `test` 클러스터의 +default 네임스페이스에 적용되며 `exp-test` 컨텍스트에 나열된 사용자의 자격증명을 사용할 것이다. -현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자. +현재의 컨텍스트인 `exp-test`에 관련된 설정을 보자. ```shell kubectl config --kubeconfig=config-demo view --minify @@ -328,10 +338,10 @@ contexts: user: developer name: dev-storage - context: - cluster: scratch + cluster: test namespace: default user: experimenter - name: exp-scratch + name: exp-test ``` kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 @@ -388,6 +398,17 @@ export KUBECONFIG="$KUBECONFIG_SAVED" $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` +## kubeconfig에 의해 표시된 제목을 확인하기 + +클러스터 인증 후 어떤 속성(사용자 이름, 그룹)을 얻을 수 있는지 항상 명확하지는 않다. +동시에 두 개 이상의 클러스터를 관리하는 경우 훨씬 더 어려울 수 있다. + +선택되어 있는 쿠버네티스 컨텍스트의 사용자 이름 등에 대한, +주체 속성을 확인하기 위한 'kubectl' 알파 하위 명령 `kubectl alpha auth whoami`이 있다. + +더 자세한 내용은 [클라이언트의 인증 정보에 대한 API 액세스](/docs/reference/access-authn-authz/authentication/#self-subject-review) +를 확인한다. + ## {{% heading "whatsnext" %}} * [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) diff --git a/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md index 4bff231560..f39d6d858c 100644 --- a/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -198,6 +198,6 @@ spec: ## {{% heading "whatsnext" %}} +* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼을 따라하기 * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 diff --git a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md index a6f4f086d2..90a37a5af5 100644 --- a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -38,19 +38,6 @@ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c ``` - -이 커맨드는 결과값으로 나온 모든 아이템 중에 `image` 라고 명명된 필드를 -모두 출력한다. - -이와 다른 방법으로 파드 이미지 필드 값의 절대 경로를 사용할 수 있다. -이것은 필드명이 반복될 때에도 -정확한 값을 출력하도록 보장한다. -예) 결과값 중에 많은 필드들이 `name`으로 명명되었을 경우, - -```shell -kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -``` - 이 jsonpath는 다음과 같이 해석할 수 있다. - `.items[*]`: 각 결과값에 대하여 diff --git a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md index a7351040e6..55d427787f 100644 --- a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -10,26 +10,15 @@ weight: 60 위해 사용하는 쿠버네티스 서비스 오브젝트를 생성하는 방법을 설명한다. 서비스는 실행 중인 두 개의 인스턴스를 갖는 애플리케이션에 대한 로드 밸런싱을 제공한다. - - - ## {{% heading "prerequisites" %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - +{{< include "task-tutorial-prereqs.md" >}} ## {{% heading "objectives" %}} - -* Hello World 애플리케이션 인스턴스 두 개를 실행한다. -* 노드 포트를 노출하는 서비스 오브젝트를 생성한다. -* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다. - - - +- Hello World 애플리케이션 인스턴스 두 개를 실행한다. +- 노드 포트를 노출하는 서비스 오브젝트를 생성한다. +- 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다. @@ -41,9 +30,11 @@ weight: 60 1. 클러스터 내 Hello World 애플리케이션을 실행하자. 위 파일을 사용하여 애플리케이션 디플로이먼트를 생성하자. + ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` + 앞의 명령은 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 오브젝트와 연관된 @@ -52,29 +43,34 @@ weight: 60 {{< glossary_tooltip text="파드" term_id="pod" >}}를 갖고, 각각은 Hello World 애플리케이션을 실행한다. - 1. 디플로이먼트에 대한 정보를 보여준다. + ```shell kubectl get deployments hello-world kubectl describe deployments hello-world ``` 1. 레플리카셋 오브젝트에 대한 정보를 보여준다. + ```shell kubectl get replicasets kubectl describe replicasets ``` 1. 디플로이먼트를 노출하는 서비스 오브젝트를 생성한다. + ```shell kubectl expose deployment hello-world --type=NodePort --name=example-service ``` 1. 서비스에 대한 정보를 보여준다. + ```shell kubectl describe services example-service ``` + 결과는 아래와 같다. + ```shell Name: example-service Namespace: default @@ -90,19 +86,24 @@ weight: 60 Session Affinity: None Events: ``` + 서비스의 노드포트(NodePort) 값을 메모하자. 예를 들어, 앞선 결과에서, 노드포트 값은 31496이다. 1. Hello World 애플리케이션이 실행 중인 파드를 나열한다. + ```shell kubectl get pods --selector="run=load-balancer-example" --output=wide ``` + 결과는 아래와 같다. + ```shell NAME READY STATUS ... IP NODE hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1 hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2 ``` + 1. Hello World 파드가 실행 중인 노드들 중 하나의 노드에 대해 공용 IP 주소를 얻자. 이 주소를 얻는 방법은 어떻게 클러스터를 설치했는지에 따라 다르다. 예를 들어, Minikube를 사용하면, `kubectl cluster-info`를 @@ -117,12 +118,15 @@ weight: 60 클라우드 공급자는 방화벽 규칙을 설정하는 다른 방법을 제공한다. 1. Hello World 애플리케이션 접근을 위해 노드 주소와 노드 포트를 사용하자. + ```shell curl http://: ``` + ``는 노드의 공용 IP 주소이고, ``는 서비스의 노드포트 값이다. 성공적인 요청에 대한 응답은 hello 메시지이다. + ```shell Hello Kubernetes! ``` @@ -133,12 +137,8 @@ weight: 60 [서비스 설정 파일](/ko/docs/concepts/services-networking/service/)을 사용해 서비스를 생성할 수 있다. - - - ## {{% heading "cleanup" %}} - 서비스를 삭제하기 위해 다음 명령어를 입력하자. kubectl delete services example-service @@ -148,11 +148,8 @@ weight: 60 kubectl delete deployment hello-world - - - ## {{% heading "whatsnext" %}} - -[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 -대해 더 알아본다. +튜토리얼 +[서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) +따라하기 \ No newline at end of file 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 3ea3381880..49f4244fe0 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -1,6 +1,7 @@ --- title: 쿠버네티스 API를 사용하여 클러스터에 접근하기 content_type: task +weight: 60 --- diff --git a/content/ko/docs/tasks/administer-cluster/certificates.md b/content/ko/docs/tasks/administer-cluster/certificates.md index 3cbeae35fc..089971c696 100644 --- a/content/ko/docs/tasks/administer-cluster/certificates.md +++ b/content/ko/docs/tasks/administer-cluster/certificates.md @@ -1,12 +1,12 @@ --- title: 인증서 content_type: task -weight: 20 +weight: 30 --- -클라이언트 인증서로 인증을 사용하는 경우 `easyrsa`, `openssl` 또는 `cfssl` +클라이언트 인증서로 인증을 사용하는 경우 [`easyrsa`](https://github.com/OpenVPN/easy-rsa), [`openssl`](https://github.com/openssl/openssl) 또는 [`cfssl`](https://github.com/cloudflare/cfssl) 을 통해 인증서를 수동으로 생성할 수 있다. @@ -18,7 +18,7 @@ weight: 20 1. `easyrsa3`의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다. ```shell - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz tar xzf easy-rsa.tar.gz cd easy-rsa-master/easyrsa3 ./easyrsa init-pki @@ -140,7 +140,7 @@ weight: 20 ```shell openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf + -extensions v3_ext -extfile csr.conf -sha256 ``` 1. 인증서 서명 요청을 확인한다. From bfd26ffc0db3b02348784d83832243b9c2f7271c Mon Sep 17 00:00:00 2001 From: namuk2004 Date: Sun, 16 Apr 2023 11:32:15 +0900 Subject: [PATCH 38/69] Update outdated files in dev-1.26-ko.1 (M10-M13) --- .../cluster-administration/networking.md | 2 +- .../cluster-administration/proxies.md | 2 +- .../cluster-administration/system-logs.md | 52 +++++---- .../cluster-administration/system-metrics.md | 107 +++++++++++++----- 4 files changed, 110 insertions(+), 53 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index cc3df4d5f5..1a6ce86090 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -15,7 +15,7 @@ weight: 50 {{< glossary_tooltip text="파드" term_id="pod" >}}와 `localhost` 통신으로 해결된다. 2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다. 3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. -4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. +4. 외부와 서비스 간 통신: 이 문제도 서비스에서 다룬다. diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index 28599acdfa..9e777e1368 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -1,7 +1,7 @@ --- title: 쿠버네티스에서 프락시(Proxy) content_type: concept -weight: 90 +weight: 100 --- diff --git a/content/ko/docs/concepts/cluster-administration/system-logs.md b/content/ko/docs/concepts/cluster-administration/system-logs.md index 0affb15259..a88956dadd 100644 --- a/content/ko/docs/concepts/cluster-administration/system-logs.md +++ b/content/ko/docs/concepts/cluster-administration/system-logs.md @@ -4,14 +4,16 @@ # - 44past4 title: 시스템 로그 content_type: concept -weight: 60 +weight: 80 --- 시스템 컴포넌트 로그는 클러스터에서 발생하는 이벤트를 기록하며, 이는 디버깅에 아주 유용하다. 더 많거나 적은 세부 정보를 표시하도록 다양하게 로그를 설정할 수 있다. -로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, 이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 표시하는 것처럼 세밀할 수 있다. +로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, +이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 +표시하는 것처럼 세밀할 수 있다. @@ -39,14 +41,13 @@ klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/refer - `--skip-log-headers` - `--stderrthreshold` -출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다. -출력 리다이렉션은 쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다. -이는 POSIX 셸 또는 systemd와 같은 도구일 수 -있다. +출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다. 출력 리다이렉션은 +쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다. 이는 POSIX +셸 또는 systemd와 같은 도구일 수 있다. -배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서, -위의 옵션은 사용할 수 없다. -그런 경우 출력을 리다이렉트하기 위해 +배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서, 위의 옵션은 +사용할 수 없다. 그런 경우 +출력을 리다이렉트하기 위해 [`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md) 바이너리를 쿠버네티스 컴포넌트의 래퍼(wrapper)로 사용할 수 있다. 미리 빌드된 바이너리가 몇몇 쿠버네티스 베이스 이미지에 기본 이름 `/go-runner` 와 @@ -63,31 +64,34 @@ klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/refer ### Klog 출력 -klog 네이티브 형식 예 : +klog 네이티브 형식 예 : + ``` I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] ``` 메시지 문자열은 줄바꿈을 포함하고 있을 수도 있다. + ``` I1025 00:15:15.525108 1 example.go:79] This is a message which has a line break. ``` - ### 구조화된 로깅 {{< feature-state for_k8s_version="v1.23" state="beta" >}} {{< warning >}} -구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다. +구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. +로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다. 로그 형식 및 값 직렬화는 변경될 수 있다. {{< /warning>}} -구조화된 로깅은 로그 메시지에 통일된 구조를 적용하여 정보를 쉽게 추출하고, -로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다. -새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다. +구조화된 로깅은 로그 메시지에 유니폼 구조를 적용하여 +정보를 쉽게 추출하고, 로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다. +로그 메세지를 생성하는 코드는 기존의 구조화되지 않은 klog 출력을 사용 또는 +구조화된 로깅을 사용할지 여부를 결정합니다. 구조화된 로그 메시지의 기본 형식은 텍스트이며, 기존 klog와 하위 호환되는 형식이다. @@ -105,6 +109,7 @@ I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod= 문자열은 따옴표로 감싸진다. 다른 값들은 [`%+v`](https://pkg.go.dev/fmt#hdr-Printing)로 포맷팅되며, 이로 인해 [데이터에 따라](https://github.com/kubernetes/kubernetes/issues/106428) 로그 메시지가 다음 줄로 이어질 수 있다. + ``` I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line, second line.} @@ -164,15 +169,18 @@ I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s" {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{}} -JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다. +JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, +[커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다. -모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다. +모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). +로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다. 필드 이름과 JSON 직렬화는 변경될 수 있다. {{< /warning >}} `--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다. JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다. + ```json { "ts": 1580306777.04728, @@ -186,14 +194,15 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다. } ``` -특별한 의미가 있는 키: +특별한 의미가 있는 키: + * `ts` - Unix 시간의 타임스탬프 (필수, 부동 소수점) * `v` - 자세한 정도 (필수, 정수, 기본 값 0) * `err` - 오류 문자열 (선택 사항, 문자열) * `msg` - 메시지 (필수, 문자열) - 현재 JSON 형식을 지원하는 컴포넌트 목록: + * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} * {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} @@ -201,8 +210,9 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다. ### 로그 상세 레벨(verbosity) -`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다. -로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다. +`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. +값을 줄이면 기록된 이벤트 수가 줄어든다. 로그 상세 레벨(verbosity)를 높이면 +점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다. ### 로그 위치 diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index 47abc62aba..0d99eeeeb4 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -5,12 +5,13 @@ title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭 # - logicalhan # - RainbowMango content_type: concept -weight: 60 +weight: 70 --- -시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. +시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 +대시보드와 경고를 만드는 데 특히 유용하다. 쿠버네티스 컴포넌트의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다. 이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다. @@ -19,7 +20,8 @@ weight: 60 ## 쿠버네티스의 메트릭 -대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. 기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다. +대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. +기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다. 해당 컴포넌트의 예는 다음과 같다. @@ -29,13 +31,18 @@ weight: 60 * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} -프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 시계열 데이터베이스에서 사용할 수 있도록 -[프로메테우스 서버](https://prometheus.io/) 또는 다른 메트릭 수집기(scraper)를 구성할 수 있다. +프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 +시계열 데이터베이스에서 사용할 수 있도록 [프로메테우스 서버](https://prometheus.io/) 또는 +다른 메트릭 수집기(scraper)를 구성할 수 있다. -참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 `/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. 이러한 메트릭은 동일한 라이프사이클을 가지지 않는다. +참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 +`/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. +이러한 메트릭은 동일한 라이프사이클을 가지지 않는다. -클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다. +클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 +`/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다. 예를 들면, 다음과 같다. + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -55,6 +62,7 @@ rules: 알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. 안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다. + * 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다. * 안정적인 메트릭의 유형(type)은 수정되지 않는다. @@ -79,34 +87,52 @@ some_counter 0 some_counter 0 ``` -히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. +히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. +히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. 삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다. - ## 히든 메트릭 표시 -위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다. +위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. +관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 +관리자를 위한 임시방편으로 사용된다. -`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다. +`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 +버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, +y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. +그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다. -플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 `show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다. +플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 +`show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. +사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다. -1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다. +1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. +메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다. * `1.n` 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다. -* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다. +* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, + `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다. * `1.n+2` 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다. -릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. +릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, +커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, +`1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. ## 액셀러레이터 메트릭 비활성화 -kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다. +kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. 이러한 메트릭을 수집하기 위해, +NVIDIA GPU와 같은 액셀러레이터의 경우, kubelet은 드라이버에 열린 핸들을 가진다. +이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해, +클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다. -액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다. +액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. +공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 +컨테이너를 제공해야 한다. -[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다. +[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text=DisableAcceleratorUsageMetrics,-false)는 +[이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 +사용하여 kubelet에서 수집한 메트릭을 비활성화한다. ## 컴포넌트 메트릭 @@ -117,7 +143,8 @@ kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVID etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어 클러스터의 상태를 측정하는 데 사용할 수 있다. -쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다. +쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 +상세한 Cloudprovider 메트릭을 사용할 수 있다. 이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다. 예를 들어, GCE의 경우 이러한 메트릭을 다음과 같이 호출한다. @@ -136,9 +163,15 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} {{< feature-state for_k8s_version="v1.21" state="beta" >}} -스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다. +스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. +이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, +현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, +실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다. + +kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. +요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. +시계열에는 다음과 같은 레이블이 지정된다. -kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다. - 네임스페이스 - 파드 이름 - 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열 @@ -147,32 +180,46 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k - 리소스 이름 (예: `cpu`) - 알려진 경우 리소스 단위 (예: `cores`) -파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다. +파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 +`Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) +스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. +두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다. -메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트 -와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다. +메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 +스케줄러의 `/metrics` 엔드포인트와 동일한 인증이 필요하다. +이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다. ## 메트릭 비활성화 -커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`). +커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. +이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. +입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`). ## 메트릭 카디널리티(cardinality) 적용 -제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다. +제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. +리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 +메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다. 알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다. 각 매핑은 `,=` 형식이다. 여기서 `` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다. 전체 형식은 다음과 같다. -`--allow-label-value ,=', ...', ,=', ...', ...`. + +``` +--allow-label-value ,=', ...', ,=', ...', ... +``` 예시는 다음과 같다. -`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'` +```none +--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday' +``` ## {{% heading "whatsnext" %}} -* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다 +* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) + 에 대해 읽어본다 * [안정 버전의 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 살펴본다 -* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 +* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 \ No newline at end of file From 007890fd476fcea704560eecf0b6a1aa5047d3b2 Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Sat, 25 Mar 2023 19:10:50 +0900 Subject: [PATCH 39/69] [ko] translate secrets-good-practices.md into Korean --- .../security/secrets-good-practices.md | 116 ++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 content/ko/docs/concepts/security/secrets-good-practices.md diff --git a/content/ko/docs/concepts/security/secrets-good-practices.md b/content/ko/docs/concepts/security/secrets-good-practices.md new file mode 100644 index 0000000000..47e2575cb0 --- /dev/null +++ b/content/ko/docs/concepts/security/secrets-good-practices.md @@ -0,0 +1,116 @@ +--- +title: 쿠버네티스 시크릿 모범 사례 +description: > + 클러스터 운영자와 애플리케이션 개발자를 위한 모범 시크릿 관리 규칙 및 사례. +content_type: concept +weight: 70 +--- + + + +{{}} + +다음 모범 사례는 클러스터 관리자와 애플리케이션 개발자 모두를 위한 것이다. +이 가이드라인을 사용하여 시크릿 오브젝트에 있는 +민감한 정보의 보안을 개선하고 +시크릿을 보다 효과적으로 관리할 수 있다. + + + +## 클러스터 관리자 + +이 섹션에서는 클러스터 관리자가 클러스터의 기밀 정보 보안을 개선하는 데 +사용할 수 있는 모범 사례를 제공한다. + +### 저장된 데이터(at rest)에 암호화 구성 + +기본적으로 시크릿 오브젝트는 {{}}에 +암호화되지 않은 상태로 저장된다. 따라서 `etcd`의 시크릿 데이터에 암호화를 구성해야 한다. +자세한 내용은 +[Encrypt Secret Data at Rest](/docs/tasks/administer-cluster/encrypt-data/)를 참고한다. + +### 시크릿에 대한 최소 권한 접근 구성 {#least-privilege-secrets} + +쿠버네티스 {{}} +[(RBAC)](/ko/docs/reference/access-authn-authz/rbac/)와 같은 접근 제어 메커니즘을 계획할 때, +`Secret` 오브젝트에 대한 접근에 대해 다음 가이드라인을 고려한다. 또한 +[역할 기반 접근 제어 (RBAC) 모범 사례](/ko/docs/concepts/security/rbac-good-practices)의 +다른 가이드라인도 따라야 한다. + +- **컴포넌트**: 가장 권한이 높은 시스템 수준의 구성 요소에 대해서만 + `watch`나 `list` 액세스를 제한한다. 컴포넌트의 정상 동작에 필요한 경우에만 + 시크릿에 대한 `get` 액세스를 허용한다. +- **사람**: 시크릿에 `get`, `watch` 또는 `list` 액세스를 제한한다. 클러스터 관리자에게만 + `etcd`에 대한 액세스를 허용한다. 여기에는 읽기 전용 액세스가 포함된다. 특정 어노테이션을 + 사용하여 시크릿에 대한 액세스를 제한하는 등의 더 복잡한 액세스 제어를 수행하려면 + 써드파티(third-party) 권한 부여 메커니즘을 사용하는 것을 고려한다. + +{{< caution >}} +시크릿에 대한 `list` 액세스 권한을 부여하면 주체가 암시적으로 +시크릿의 내용을 가져갈 수 있다. +{{< /caution >}} + +시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다. +클러스터 정책에서 사용자가 시크릿을 직접 읽는 것을 허용하지 않더라도, +동일한 사용자가 시크릿을 노출하는 파드를 실행할 수 있다. +이 액세스 권한을 가진 사용자가 의도적이든 의도적이지 않든 시크릿 데이터를 노출시켜 +발생할 수 있는 영향을 감지하거나 제한할 수 있다. +몇 가지 권장 사항은 다음과 같다. + +* 수명이 짧은 시크릿 사용 +* 한 사용자가 여러 비밀을 동시에 읽는 것과 같은 특정 이벤트에 대해 + 경고하는 감사 규칙 구현 + +### etcd 관리 정책 개선 + +더 이상 사용하지 않는다면 `etcd`에서 사용하는 내구성 스토리지를 +지우거나 파쇄하는 것을 고려한다. + +여러 개의 `etcd` 인스턴스가 있는 경우, 인스턴스 간에 암호화된 SSL/TLS 통신을 구성하여 +전송 중(in transit)인 시크릿 데이터를 보호한다. + +### 외부 시크릿에 대한 액세스 구성 + +{{% thirdparty-content %}} + +써드파티 시크릿 저장소 공급자를 사용하여 기밀 데이터를 클러스터 외부에 보관한 다음 +해당 정보에 액세스하도록 파드를 구성할 수 있다. +[쿠버네티스 시크릿 스토어 CSI 드라이버](https://secrets-store-csi-driver.sigs.k8s.io/)는 +kubelet이 외부 스토어에서 시크릿을 검색하고 +접근 권한을 부여한 특정 파드에 시크릿을 볼륨으로 마운트할 수 있도록 하는 +데몬셋(DaemonSet)이다. + +지원되는 제공자 목록은 다음을 참고한다. +[시크릿 스토어 CSI 드라이버 제공자](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver). + +## 개발자 + +이 섹션은 개발자가 쿠버네티스 리소스를 구축하고 배포할 때 +기밀 데이터의 보안을 개선하기 위해 사용할 수 있는 모범 사례를 제공한다. + +### 특정 컨테이너에 시크릿 액세스 제한 + +파드에 여러 개의 컨테이너를 정의하고 있고 그 중 하나만 시크릿에 접근해야 하는 경우, +볼륨 마운트 또는 환경 변수 구성을 정의하여 +다른 컨테이너가 해당 시크릿에 액세스하지 못하도록 +한다. + +### 읽기 후 시크릿 데이터 보호 + +애플리케이션은 환경 변수나 볼륨에서 기밀 정보를 읽은 후에도 그 값을 보호해야 한다. +예를 들어, 애플리케이션은 시크릿 데이터를 로그에 남기거나 +신뢰할 수 없는 상대에게 +전송하지 않아야 한다. + +### 시크릿 매니페스트 공유 방지 + +시크릿 데이터가 base64로 인코딩된 +{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 통해 시크릿을 구성하는 경우, +이 파일을 공유하거나 소스 리포지토리에 체크인하면 매니페스트를 읽을 수 있는 모든 사람이 +시크릿을 사용할 수 있다는 것을 의미한다. + +{{}} +Base64 인코딩은 암호화 방식이 _아니며_, 일반 텍스트에 비해 추가적인 +기밀성을 제공하지 않는다. +{{}} From 09724a67e6eb24c252b7a2d6194e2dc50606d5bf Mon Sep 17 00:00:00 2001 From: jongwooo Date: Thu, 27 Apr 2023 10:18:27 +0900 Subject: [PATCH 40/69] [ko] Update outdated files in dev-1.26-ko.1 (M34-M41) Signed-off-by: jongwooo --- .../working-with-objects/annotations.md | 2 +- .../working-with-objects/common-labels.md | 1 + .../working-with-objects/field-selectors.md | 3 +- .../working-with-objects/finalizers.md | 2 +- .../kubernetes-objects.md | 2 ++ .../overview/working-with-objects/names.md | 4 +-- .../working-with-objects/namespaces.md | 33 ++++++++++++------- .../working-with-objects/object-management.md | 2 +- 8 files changed, 32 insertions(+), 17 deletions(-) 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 89334978c0..a1acb8b51d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -1,7 +1,7 @@ --- title: 어노테이션 content_type: concept -weight: 50 +weight: 60 --- diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index 05022d47c5..28b7e6d43d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -1,6 +1,7 @@ --- title: 권장 레이블 content_type: concept +weight: 100 --- diff --git a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md index cb16ce9d58..7b8bf9c092 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md @@ -1,6 +1,7 @@ --- title: 필드 셀렉터 -weight: 60 +content_type: concept +weight: 70 --- _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버네티스 리소스를 선택](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/finalizers.md b/content/ko/docs/concepts/overview/working-with-objects/finalizers.md index e19d80d390..3f7aa999a2 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/ko/docs/concepts/overview/working-with-objects/finalizers.md @@ -1,7 +1,7 @@ --- title: 파이널라이저 content_type: concept -weight: 60 +weight: 80 --- diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index e4b69599b6..5dd33631c5 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -8,10 +8,12 @@ card: --- + 이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다. + ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects} *쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 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 b4cfe0280c..f158f195da 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -4,7 +4,7 @@ # - thockin title: 오브젝트 이름과 ID content_type: concept -weight: 20 +weight: 30 --- @@ -99,5 +99,5 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다. ## {{% heading "whatsnext" %}} -* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기. +* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)에 대해 읽기. * [쿠버네티스의 식별자와 이름](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) 디자인 문서 읽기. diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index b09903e11c..ceadf9e2ea 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -5,7 +5,7 @@ # - thockin title: 네임스페이스 content_type: concept -weight: 30 +weight: 45 --- @@ -32,6 +32,26 @@ weight: 30 구별하기 위해 {{< glossary_tooltip text="레이블" term_id="label" >}}을 사용한다. +{{< note >}} +프로덕션 클러스터의 경우, `default` 네임스페이스를 _사용하지 않는_ 것을 고려한다. 대신에, 다른 네임스페이스를 만들어 사용한다. +{{< /note >}} + +## 초기 네임스페이스 + +쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다. + +`default` +: 쿠버네티스에는 이 네임스페이스가 포함되어 있으므로 먼저 네임스페이스를 생성하지 않고도 새 클러스터를 사용할 수 있다. + +`kube-node-lease` +: 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다. + +`kube-public` +: 이 네임스페이스는 **모든** 클라이언트(인증되지 않은 클라이언트 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. + +`kube-system` +: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스. + ## 네임스페이스 다루기 네임스페이스의 생성과 삭제는 @@ -56,15 +76,6 @@ kube-public Active 1d kube-system Active 1d ``` -쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다. - - * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 - * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 - * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. - * `kube-node-lease` 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) - 오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를 - 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다. - ### 요청에 네임스페이스 설정하기 현재 요청에 대한 네임스페이스를 설정하기 위해서 `--namespace` 플래그를 사용한다. @@ -120,7 +131,7 @@ kubectl config view --minify | grep namespace: 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. 그리고 [노드](/ko/docs/concepts/architecture/nodes/)나 -퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 +[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다. 다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index dba1e3c510..640c0ad8aa 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -1,7 +1,7 @@ --- title: 쿠버네티스 오브젝트 관리 content_type: concept -weight: 15 +weight: 20 --- From 5d0067f223372869846d2d6ba129673981c3094a Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Sat, 29 Apr 2023 19:39:04 +0900 Subject: [PATCH 41/69] Update outdated korean contents in dev-1.26-ko.1 (M42-M44) --- content/ko/docs/concepts/policy/_index.md | 5 ++ .../ko/docs/concepts/policy/limit-range.md | 65 ++++++++++++++----- .../docs/concepts/policy/resource-quotas.md | 12 ++++ .../example-conflict-with-limitrange-cpu.yaml | 11 ++++ ...ample-no-conflict-with-limitrange-cpu.yaml | 13 ++++ .../limit-range/problematic-limit-range.yaml | 14 ++++ 6 files changed, 104 insertions(+), 16 deletions(-) create mode 100644 content/ko/examples/concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml create mode 100644 content/ko/examples/concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml create mode 100644 content/ko/examples/concepts/policy/limit-range/problematic-limit-range.yaml diff --git a/content/ko/docs/concepts/policy/_index.md b/content/ko/docs/concepts/policy/_index.md index 425e725037..e3b01aea8b 100644 --- a/content/ko/docs/concepts/policy/_index.md +++ b/content/ko/docs/concepts/policy/_index.md @@ -4,3 +4,8 @@ weight: 90 description: > 리소스의 그룹에 적용되도록 구성할 수 있는 정책 --- + +{{< note >}} +쿠버네티스의 네트워크폴리시(NetworkPolicy)에 대한 설명은 +[네트워크 정책](/ko//docs/concepts/services-networking/network-policies/)을 참고한다. +{{< /note >}} diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index 966adf3d76..6082d186e6 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -9,21 +9,23 @@ weight: 10 기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)로 실행된다. -리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다. -네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. +쿠버네티스의 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하면 +클러스터 관리자(또는 _클러스터 오퍼레이터_ 라고 함)는 +{{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 +리소스(CPU 시간, 메모리 및 퍼시스턴트 스토리지) 사용과 생성을 제한할 수 있다. +네임스페이스 내에서 {{< glossary_tooltip text="파드" term_id="Pod" >}}는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 클러스터 운영자 또는 네임스페이스 수준 관리자는 단일 오브젝트가 네임스페이스 내에서 사용 가능한 모든 리소스를 독점하지 못하도록 하는 것에 대해 우려할 수도 있다. + +리밋레인지는 네임스페이스의 각 적용 가능한 오브젝트 종류(예: 파드 또는 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}})에 대해 지정할 수 있는 리소스 할당(제한 및 요청)을 제한하는 정책이다. _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - 네임스페이스에서 파드 또는 컨테이너별 최소 및 최대 컴퓨팅 리소스 사용량을 지정한다. -- 네임스페이스에서 스토리지클래스별 최소 및 최대 스토리지 요청을 지정한다. +- 네임스페이스에서 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}별 최소 및 최대 스토리지 요청을 지정한다. - 네임스페이스에서 리소스에 대한 요청과 제한 사이의 비율을 지정한다. - 네임스페이스에서 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임에 있는 컨테이너에 자동으로 설정한다. -## 리밋레인지 활성화 - -쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다. 해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다. @@ -31,17 +33,47 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -### 리밋 레인지 개요 +### 리소스 제한 및 요청에 대한 제약 -- 관리자는 하나의 네임스페이스에 하나의 리밋레인지를 만든다. -- 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다. -- `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다. -- 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. -- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 +- 관리자는 네임스페이스에 리밋레인지를 생성한다. +- 사용자는 해당 네임스페이스에서 파드 또는 퍼시스턴트볼륨클레임과 같은 오브젝트를 생성하거나 생성하려고 시도한다. +- 첫째, `LimitRange` 어드미션 컨트롤러는 컴퓨팅 리소스 요구사항을 설정하지 않은 모든 파드(및 해당 컨테이너)에 대해 기본 요청 및 제한 값을 적용한다. +- 둘째, `LimitRange`는 사용량을 추적하여 네임스페이스에 존재하는 `LimitRange`에 정의된 리소스 최소, 최대 및 비율을 초과하지 않는지 확인한다. +- 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하려고 하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. +- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 + 리밋레인지를 추가한 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. -- 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다. +- `LimitRange` 유효성 검사는 실행 중인 파드가 아닌 파드 어드미션 단계에서만 수행된다. + 리밋레인지가 추가되거나 수정되면, 해당 + 네임스페이스에 이미 존재하는 파드는 변경되지 않고 계속 유지된다. +- 네임스페이스에 두 개 이상의 `LimitRange` 오브젝트가 존재하는 경우, 어떤 기본값이 적용될지는 결정적이지 않다. -리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다. +## 파드에 대한 리밋레인지 및 어드미션 확인 + +`LimitRange`는 적용하는 기본값의 일관성을 확인하지 **않는다**. 즉, `LimitRange`에 의해 설정된 _limit_ 의 기본값이 클라이언트가 API 서버에 제출하는 스펙에서 컨테이너에 지정된 _request_ 값보다 작을 수 있다. 이 경우, 최종 파드는 스케줄링할 수 없다. + +예를 들어, 이 매니페스트에 `LimitRange`를 정의한다. + +{{< codenew file="concepts/policy/limit-range/problematic-limit-range.yaml" >}} + + +이 때 CPU 리소스 요청을 `700m`로 선언하지만 제한은 선언하지 않는 파드를 포함한다. + +{{< codenew file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" >}} + + +그러면 해당 파드는 스케줄링되지 않고 다음과 유사한 오류와 함께 실패한다. +``` +Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit +``` + +`request`와 `limit`를 모두 설정하면, 동일한 `LimitRange`가 적용되어 있어도 새 파드는 성공적으로 스케줄링된다. + +{{< codenew file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" >}} + +## 리소스 제약 예시 + +`LimitRange`를 사용하여 생성할 수 있는 정책의 예는 다음과 같다. - 용량이 8GiB RAM과 16 코어인 2 노드 클러스터에서 네임스페이스의 파드를 제한하여 CPU의 최대 제한이 500m인 CPU 100m를 요청하고 메모리의 최대 제한이 600M인 메모리 200Mi를 요청하라. - 스펙에 CPU 및 메모리 요청없이 시작된 컨테이너에 대해 기본 CPU 제한 및 요청을 150m로, 메모리 기본 요청을 300Mi로 정의하라. @@ -53,8 +85,6 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. ## {{% heading "whatsnext" %}} -자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다. - 제한의 사용에 대한 예시는 다음을 참조한다. - [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). @@ -63,3 +93,6 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). - [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/ko/docs/tasks/administer-cluster/limit-storage-consumption/#스토리지-요청을-제한하기-위한-리밋레인지-limitrange). - [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). + +컨텍스트 및 기록 정보는 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다. + diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index cdcd0d36cb..ed66cfd72c 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -39,6 +39,18 @@ weight: 20 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. +{{< note >}} +- 리소스쿼터는 `cpu` 및 `memory` 리소스의 경우, 해당 네임스페이스의 **모든** +(신규) 파드가 해당 리소스에 대한 제한을 설정하도록 강제한다. +네임스페이스에서 `cpu` 또는 `memory`에 대해 리소스 할당량을 적용하는 경우, +사용자와 다른 클라이언트는 **반드시** 제출하는 모든 새 파드에 대해 +해당 리소스에 `requests` 또는 `limits` 중 하나를 지정해야 한다. +그렇지 않으면 컨트롤 플레인이 해당 파드에 대한 어드미션을 거부할 수 있다. +- 다른 리소스의 경우: 리소스쿼터는 작동하며 해당 리소스에 대한 제한이나 요청을 설정하지 않고 네임스페이스의 파드를 무시한다. 즉, 리소스 쿼터가 이 네임스페이스의 임시 스토리지를 제한하는 경우 임시 스토리지를 제한/요청하지 않고 새 파드를 생성할 수 있다. +[리밋 레인지(Limit Range)](/ko/docs/concepts/policy/limit-range/)를 사용하여 +이러한 리소스에 대한 기본 요청을 자동으로 설정할 수 있다. +{{< /note >}} + 리소스쿼터 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. diff --git a/content/ko/examples/concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml b/content/ko/examples/concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml new file mode 100644 index 0000000000..0b3aa3a6f9 --- /dev/null +++ b/content/ko/examples/concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: example-conflict-with-limitrange-cpu +spec: + containers: + - name: demo + image: registry.k8s.io/pause:2.0 + resources: + requests: + cpu: 700m diff --git a/content/ko/examples/concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml b/content/ko/examples/concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml new file mode 100644 index 0000000000..7001aec0d7 --- /dev/null +++ b/content/ko/examples/concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: example-no-conflict-with-limitrange-cpu +spec: + containers: + - name: demo + image: registry.k8s.io/pause:2.0 + resources: + requests: + cpu: 700m + limits: + cpu: 700m diff --git a/content/ko/examples/concepts/policy/limit-range/problematic-limit-range.yaml b/content/ko/examples/concepts/policy/limit-range/problematic-limit-range.yaml new file mode 100644 index 0000000000..2a19606c1d --- /dev/null +++ b/content/ko/examples/concepts/policy/limit-range/problematic-limit-range.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: cpu-resource-constraint +spec: + limits: + - default: # 이 섹션에서는 기본 한도를 정의한다 + cpu: 500m + defaultRequest: # 이 섹션에서는 기본 요청을 정의한다 + cpu: 500m + max: # max와 min은 제한 범위를 정의한다 + cpu: "1" + min: + cpu: 100m From 235be1df7d9bb462689635b668fe56b8b37a84d4 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Mon, 8 May 2023 18:53:37 +0900 Subject: [PATCH 42/69] Replace deprecated fullversion shortcode for Korean Signed-off-by: Seokho Son --- .../docs/concepts/containers/container-environment.md | 2 +- .../kubeadm/upgrading-windows-nodes.md | 8 ++++---- content/ko/docs/tasks/tools/install-kubectl-linux.md | 4 ++-- content/ko/docs/tasks/tools/install-kubectl-macos.md | 6 +++--- .../ko/docs/tasks/tools/install-kubectl-windows.md | 11 ++++++----- .../services/connect-applications-service.md | 2 +- 6 files changed, 17 insertions(+), 16 deletions(-) diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 9970b4d7d7..3fee2a14e8 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -51,7 +51,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> FOO_SERVICE_PORT=<서비스가 동작 중인 포트> ``` -서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. +서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index fe7597fdf1..a35a3b4c32 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -33,8 +33,8 @@ weight: 40 1. 윈도우 노드에서, kubeadm을 업그레이드한다. ```powershell - # {{< param "fullversion" >}}을 사용 중인 쿠버네티스 버전으로 변경한다. - curl.exe -Lo "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe" + # {{< skew currentPatchVersion >}}을 사용 중인 쿠버네티스 버전으로 변경한다. + curl.exe -Lo "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubeadm.exe" ``` ### 노드 드레인 @@ -68,7 +68,7 @@ weight: 40 ```powershell stop-service kubelet - curl.exe -Lo "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe" + curl.exe -Lo "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubelet.exe" restart-service kubelet ``` @@ -76,7 +76,7 @@ weight: 40 ```powershell stop-service kube-proxy - curl.exe -Lo "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kube-proxy.exe" + curl.exe -Lo "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kube-proxy.exe" restart-service kube-proxy ``` diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index f29354ebbf..8fc7aa844b 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -34,10 +34,10 @@ card: {{< note >}} 특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. -예를 들어, 리눅스에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. +예를 들어, 리눅스에서 버전 {{< skew currentPatchVersion >}}을 다운로드하려면, 다음을 입력한다. ```bash - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl + curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl ``` {{< /note >}} diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index f2bf94132a..cc018985b2 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -39,16 +39,16 @@ card: {{< note >}} 특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. - 예를 들어, Intel macOS에 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. + 예를 들어, Intel macOS에 버전 {{< skew currentPatchVersion >}}을 다운로드하려면, 다음을 입력한다. ```bash - curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl" + curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/amd64/kubectl" ``` Apple Silicon의 macOS라면, 다음을 입력한다. ```bash - curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/arm64/kubectl" + curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/arm64/kubectl" ``` {{< /note >}} diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md index 8ebe78c103..2a381a3ee9 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-windows.md +++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md @@ -24,12 +24,13 @@ card: ### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows} -1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다. +1. 최신 패치 릴리스 {{< skew currentVersion >}} 다운로드: + [kubectl {{< skew currentPatchVersion >}}](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe) 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. ```powershell - curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe" + curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe" ``` {{< note >}} @@ -41,7 +42,7 @@ card: `kubectl` 체크섬 파일을 다운로드한다. ```powershell - curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256" + curl -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe.sha256" ``` `kubectl` 바이너리를 체크섬 파일을 통해 검증한다. @@ -151,7 +152,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제 1. 다음 명령으로 최신 릴리스를 다운로드한다. ```powershell - curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe" + curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe" ``` 1. 바이너리를 검증한다. (선택 사항) @@ -159,7 +160,7 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제 `kubectl-convert` 체크섬(checksum) 파일을 다운로드한다. ```powershell - curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256" + curl -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe.sha256" ``` `kubectl-convert` 바이너리를 체크섬 파일을 통해 검증한다. diff --git a/content/ko/docs/tutorials/services/connect-applications-service.md b/content/ko/docs/tutorials/services/connect-applications-service.md index b1c904fefe..bf88cebedd 100644 --- a/content/ko/docs/tutorials/services/connect-applications-service.md +++ b/content/ko/docs/tutorials/services/connect-applications-service.md @@ -135,7 +135,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외 쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를 지원한다. 전자는 기본적으로 작동하지만 후자는 -[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)이 필요하다. +[CoreDNS 클러스터 애드온](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/coredns)이 필요하다. {{< note >}} 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성, 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서 From fbc93f019f34f7b04f4996fd9b2abc17e9c9e0cb Mon Sep 17 00:00:00 2001 From: namuk2004 Date: Mon, 3 Apr 2023 17:09:28 +0900 Subject: [PATCH 43/69] Translate tasks/debug/debug-application/debug-service in Korean Translate tasks/debug/debug-application/debug-service in Korean Translate tasks/debug/debug-application/debug-service in Korean Translate tasks/debug/debug-application/debug-service in Korean Translate tasks/debug/debug-application/debug-service in Korean --- .../debug/debug-application/debug-service.md | 704 ++++++++++++++++++ 1 file changed, 704 insertions(+) create mode 100644 content/ko/docs/tasks/debug/debug-application/debug-service.md diff --git a/content/ko/docs/tasks/debug/debug-application/debug-service.md b/content/ko/docs/tasks/debug/debug-application/debug-service.md new file mode 100644 index 0000000000..ad4ede5b3e --- /dev/null +++ b/content/ko/docs/tasks/debug/debug-application/debug-service.md @@ -0,0 +1,704 @@ +--- +# reviewers: +# - thockin +# - bowei +content_type: task +title: 서비스 디버깅하기 +weight: 20 +--- + + +쿠버네티스를 새로 설치할 때 자주 발생하는 문제 중 하나는 +서비스가 제대로 작동하지 않는 현상이다. 디플로이먼트(또는 다른 워크로드 컨트롤러)를 통해 파드를 실행하고 +서비스를 생성했지만, +해당 서비스에 엑세스하려고 하면 응답이 없는 경우이다. 이 문서를 통해 무엇이 잘못되었는지 +파악하는 데 도움이 되기를 바란다. + + + +## 파드 안에서 명령어 실행 + +이 페이지의 많은 단계에서, 클러스터 내에 실행 중인 파드가 어떤 것을 보고 있는지 +알고 싶을 것이다. 이를 수행하는 가장 간단한 방법은 대화형 busybox 파드를 실행하는 것이다: + +```none +kubectl run -it --rm --restart=Never busybox --image=gcr.io/google-containers/busybox sh +``` + +{{< note >}} +명령 프롬프트가 보이지 않으면, enter를 눌러 본다. +{{< /note >}} + +사용하려는 파드가 이미 실행 중인 경우, 다음을 사용하여 +명령을 실행할 수 있다. + +```shell +kubectl exec -c -- +``` + +## 설정 + +연습을 위해, 파드를 몇 개 실행한다. +자신이 관리하는 서비스를 디버깅하는 경우에는 세부 사항을 상황에 맞게 변경하고, +아니면 아래의 과정을 그대로 수행하여 두 번째 데이터 포인트를 얻을 수 있다. + +```shell +kubectl create deployment hostnames --image=registry.k8s.io/serve_hostname +``` +```none +deployment.apps/hostnames created +``` + +`kubectl` 명령어는 생성되거나 변경된 리소스의 유형과 이름을 출력하여, 여기서 출력된 리소스 유형과 이름은 다음 명령어에 사용할 수 있다. + +디플로이먼트의 레플리카를 3개로 확장한다. +```shell +kubectl scale deployment hostnames --replicas=3 +``` +```none +deployment.apps/hostnames scaled +``` + +참고로, 위의 명령들을 실행하여 디플로이먼트를 실행하는 것은 +다음과 같은 YAML을 사용하는 것과 동일하다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: hostnames + name: hostnames +spec: + selector: + matchLabels: + app: hostnames + replicas: 3 + template: + metadata: + labels: + app: hostnames + spec: + containers: + - name: hostnames + image: registry.k8s.io/serve_hostname +``` + +"app" 레이블은 `kubectl create deployment`명령에 의해 디플로이먼트의 이름으로 자동으로 +설정된다. + +파드가 실행 중인지 확인할 수 있다. + +```shell +kubectl get pods -l app=hostnames +``` +```none +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 2m +hostnames-632524106-ly40y 1/1 Running 0 2m +hostnames-632524106-tlaok 1/1 Running 0 2m +``` + +파드가 서빙 중인지도 확인할 수 있다. 파드 IP주소의 목록을 가져온 뒤 이를 +직접 테스트할 수 있다. + +```shell +kubectl get pods -l app=hostnames \ + -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' +``` +```none +10.244.0.5 +10.244.0.6 +10.244.0.7 +``` + +연습에 사용된 컨테이너 예제는 포트 9376에서 HTTP를 통해 호스트이름을 리턴하지만, +본인의 앱을 디버깅하는 경우, +포트 번호를 파드가 수신 대기 중인 포트 번호로 대체하면 된다. + +파드 내에서 다음을 실행한다. + +```shell +for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do + wget -qO- $ep +done +``` + +다음과 같은 결과가 출력될 것이다. + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + +이 단계에서 예상한 응답을 받지 못한 경우, 파드가 +정상적이지 않거나 또는 예상했던 포트에서 수신 대기를 하지 않고 있을 가능성이 있다. +어떤 일이 발생하고 있는지 확인하는 데 `kubectl logs`가 유용할 수 있으며, +또는 파드에 직접 `kubectl exec`를 실행하고 +이를 통해 디버그을 수행해야 할 수도 있다. + +지금까지 모든 것이 계획대로 진행되었다면, 서비스가 작동하지 않는 이유를 +분석해 볼 수 있다. + +## 서비스가 존재하는가? + +여기까지 따라왔다면 아직 실제로 서비스를 생성하지 않았다는 것을 알아차렸을 것이다. +이는 의도적인 것이다. 이 단계는 때때로 잊어버리지만, +가장 먼저 확인해야 할 단계이다. + +존재하지 않는 서비스에 액세스하려고 하면 어떤 일이 발생할까? +이름을 이용하여 이 서비스를 사용하는 다른 파드가 있다면 +다음과 같은 결과를 얻을 것이다. + +```shell +wget -O- hostnames +``` +```none +Resolving hostnames (hostnames)... failed: Name or service not known. +wget: unable to resolve host address 'hostnames' +``` + +가장 먼저 확인해야 할 것은 서비스가 실제로 존재하는지 여부이다. + +```shell +kubectl get svc hostnames +``` +```none +No resources found. +Error from server (NotFound): services "hostnames" not found +``` + +이제 서비스를 생성하자. 이전에도 언급했듯이, 이것은 연습을 위한 예시이다. +본인의 서비스의 세부 사항을 여기에 입력할 수도 있다. + +```shell +kubectl expose deployment hostnames --port=80 --target-port=9376 +``` +```none +service/hostnames exposed +``` + +다시 조회해 본다. + +```shell +kubectl get svc hostnames +``` +```none +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +hostnames ClusterIP 10.0.1.175 80/TCP 5s +``` + +이제 서비스가 존재하는 것을 확인할 수 있다. + +위와 마찬가지로, 위의 명령들을 실행하여 서비스를 실행하는 것은 다음과 같은 YAML을 사용하는 것과 동일하다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app: hostnames + name: hostnames +spec: + selector: + app: hostnames + ports: + - name: default + protocol: TCP + port: 80 + targetPort: 9376 +``` + +환경설정의 전체 범위를 강조하기 위해, 여기에서 생성한 서비스는 +파드와 다른 포트 번호를 사용한다. 실제 많은 서비스에서, +이러한 값은 동일할 수 있다. + +## 대상 파드에 영향을 미치는 네트워크 폴리시 인그레스 규칙이 있는가? + +`hostnames-*` 파드로 들어오는 트래픽에 영향을 줄 수 있는 네트워크 폴리시 인그레스 규칙을 +배포하는 경우, 이를 검토해야 한다. + +자세한 내용은 [Network Policies](/docs/concepts/services-networking/network-policies/)를 참고한다. + +## 서비스가 DNS 이름으로 작동하는가? + +클라이언트가 서비스를 사용하는 가장 일반적인 방법 중 하나는 DNS 이름을 통하는 +것이다. + +동일한 네임스페이스안의 파드 안에서, 다음을 실행한다. + +```shell +nslookup hostnames +``` +```none +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + +이것이 실패하면, 파드와 서비스가 다른 네임스페이스에 있는 경우일 수 있다. +네임스페이스를 지정한 이름(namespace-qualified name)을 사용해 본다(다시 말하지만, 파드 안에서 다음을 실행한다). + +```shell +nslookup hostnames.default +``` +```none +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames.default +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + +이 방법이 성공했다면, 교차 네임스페이스 이름을 사용하기 위해 앱을 조정하거나, +또는 앱과 서비스를 동일한 네임스페이스에서 실행한다. 여전히 실패한다면, +완전히 지정된 이름(fully-qualified name)을 사용한다. + +```shell +nslookup hostnames.default.svc.cluster.local +``` +```none +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames.default.svc.cluster.local +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + +여기서 접미사: "default.svc.cluster.local"에 유의한다. +"default"는 작업 중인 네임스페이스이다. "svc"는 서비스임을 나타낸다. +"cluster.local"은 클러스터 도메인을 나타내며, +클러스터마다 다를 수 있다. + +동일한 작업을 클러스터의 노드에서 시도해 볼 수도 있다. + +{{< note >}} +10.0.0.10 은 클러스터의 DNS 서비스 IP이며, 사용자의 것과 다를 수 있다. +{{< /note >}} + +```shell +nslookup hostnames.default.svc.cluster.local 10.0.0.10 +``` +```none +Server: 10.0.0.10 +Address: 10.0.0.10#53 + +Name: hostnames.default.svc.cluster.local +Address: 10.0.1.175 +``` + +완전히 지정된 이름은 조회가 가능하지만 상대적인 이름은 조회를 할 수 없는 경우, +파드의 `/etc/resolv.conf` 파일이 올바른지 확인해야 한다. +파드 내에서 다음을 실행한다. + +```shell +cat /etc/resolv.conf +``` + +다음과 같은 내용이 표시될 것이다. + +``` +nameserver 10.0.0.10 +search default.svc.cluster.local svc.cluster.local cluster.local example.com +options ndots:5 +``` + +`nameserver` 라인은 클러스터의 DNS 서비스를 나타내야 한다. +이는 `--cluster-dns` 플래그와 함께 `kubelet`으로 전달된다. + +`search` 라인은 서비스 이름을 찾을 수 있는 적절한 접미사가 포함되어야 한다. +위 예시의 경우, ("default.svc.cluster.local" ->) 로컬 네임스페이스의 서비스, +("svc.cluster.local" ->) 모든 네임스페이스의 서비스, +마지막으로 클러스터 ("cluster.local" ->) 클러스터 범위에서 이름을 찾는다. +클러스터의 구성에 따라 그 뒤에 추가 레코드를 기입할 수도 있다(총 6개까지). +클러스터 접미사는 `--cluster-domain` 플래그와 함께 +`kubelet`에 전달된다. 이 문서에서, 클러스터 접미사는 +"cluster.local"로 간주된다. 당신의 클러스터가 다르게 구성되었을 수도 있으며, +이 경우 이전의 모든 명령어에서 이를 +변경해야 한다. + +`options` 라인의 `ndots` 값은 DNS 클라이언트 라이브러리가 모든 탐색 경우의 수를 고려할 수 있을 만큼 충분히 높게 설정되어야 한다. +쿠버네티스는 기본적으로 5로 설정하며, +이는 쿠버네티스가 생성하는 모든 DNS 이름을 포함할 수 있을 만큼 충분히 높다. + +### DNS 이름으로 동작하는 서비스가 하나라도 있는가? {#does-any-service-exist-in-dns} + +위의 작업이 계속 실패하면, 서비스에 대해 DNS 조회가 작동하지 않는 것이다. +한 걸음 뒤로 물러나서 어떤 것이 작동하지 않는지 확인할 수 있다. 쿠버네티스 마스터 +서비스는 항상 작동해야 한다. 파드 내에서 다음을 실행한다. + +```shell +nslookup kubernetes.default +``` +```none +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: kubernetes.default +Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local +``` + +이것이 실패하면, 이 문서의 [kube-proxy](#is-the-kube-proxy-working) 섹션을 참고하거나 +본 문서의 맨 위로 돌아가서 다시 시작한다. +단, 서비스를 디버깅하는 대신, DNS 서비스를 디버그한다. + +## 서비스가 IP로 작동하는가? + +DNS가 작동하는 것을 확인했다고 가정하면, 다음 테스트는 +서비스가 IP 주소로 작동하는지 확인하는 것이다. 클러스터의 파드에서, +서비스의 IP에 액세스한다(위와 같이 `kubectl get`을 사용). + +```shell +for i in $(seq 1 3); do + wget -qO- 10.0.1.175:80 +done +``` + +이렇게 하면 다음과 같은 결과가 나타난다. + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + +서비스가 작동하는 경우, 올바른 응답을 받았을 것이다. 그렇지 않은 경우, +잘못되어 있을 수 있는 여러가지 사항이 있다. 아래의 내용을 계속 읽어 본다. + +## 서비스가 올바르게 정의되었는가? + +몇 차례 강조하지만, 서비스가 정확하게 기재되어 있고 파드의 포트와 일치하는지 +두 번, 세 번 확인해야 한다. 아래의 명령을 실행하여 +서비스를 다시 조회해 본다. + +```shell +kubectl get service hostnames -o json +``` +```json +{ + "kind": "Service", + "apiVersion": "v1", + "metadata": { + "name": "hostnames", + "namespace": "default", + "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc", + "resourceVersion": "347189", + "creationTimestamp": "2015-07-07T15:24:29Z", + "labels": { + "app": "hostnames" + } + }, + "spec": { + "ports": [ + { + "name": "default", + "protocol": "TCP", + "port": 80, + "targetPort": 9376, + "nodePort": 0 + } + ], + "selector": { + "app": "hostnames" + }, + "clusterIP": "10.0.1.175", + "type": "ClusterIP", + "sessionAffinity": "None" + }, + "status": { + "loadBalancer": {} + } +} +``` + +* 액세스하려는 서비스 포트가 `spec.ports[]`에 나열되어 있는가? +* 파드에 대한 `targetPort`가 올바른가(일부 파드는 서비스와 다른 포트를 사용한다)? +* 숫자 포트를 사용하려는 경우, 자료형이 숫자(9376)인가 문자열 "9376"인가? +* 이름이 부여된 포트를 사용하려는 경우, 파드가 해당 이름의 포트를 노출하는가? +* 포트의 'protocol'이 파드의 것과 일치하는가? + +## 서비스에 엔드포인트가 있는가? + +여기까지 왔다면, 서비스가 올바르게 정의되어 있고 +DNS에 의해 해석될 수 있음을 확인한 것이다. 이제 실행 중인 파드가 +서비스에 의해 실제로 선택되고 있는지 확인한다. + +이전에 파드가 실행 중임을 확인했다. 다음 명령을 통해 다시 확인할 수 있다. + +```shell +kubectl get pods -l app=hostnames +``` +```none +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 1h +hostnames-632524106-ly40y 1/1 Running 0 1h +hostnames-632524106-tlaok 1/1 Running 0 1h +``` + +`-l app=hostnames` 인수는 서비스에 구성된 레이블 셀렉터이다. + +"AGE" 열은 파드가 실행된 지 약 1시간 되었다고 표시하는 것으로, +이는 파드가 제대로 실행되고 있으며 충돌하지 않음을 의미한다. + +"RESTARTS" 열은 파드가 자주 충돌하지 않거나 다시 시작되지 않음을 나타낸다. +잦은 재시작은 간헐적인 연결 문제를 발생할 수 있다. +재시작 횟수가 높으면, [파드를 디버깅하는](/docs/tasks/debug/debug-application/debug-pods/) 방법에 대해 참고한다. + +쿠버네티스 시스템 내부에는 모든 서비스의 셀렉터를 평가하고 +그 결과를 해당 엔드포인트 오브젝트에 저장하는 제어 루프가 있다. + +```shell +kubectl get endpoints hostnames + +NAME ENDPOINTS +hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 +``` + +위의 결과를 통해 엔드포인트 컨트롤러가 서비스에 대한 올바른 파드를 찾았음을 알 수 있다. +`ENDPOINTS` 열이 ``인 경우, +서비스의 `spec.selector` 필드가 파드의 `metadata.labels` 값을 +실제로 선택하는지 확인해야 한다. +흔한 실수로, `kubectl run` 명령으로 디플로이먼트도 생성할 수 있었던 1.18 이전 버전에서, +서비스는 `app=hostnames` 를 이용하여 파드를 선택하지만 +디플로이먼트는 `run=hostnames` 를 이용하여 파드를 선택하는 것과 같은 오타, 또는 기타 오류가 있을 수 있다. + +## 파드가 작동하고 있는가? + +여기까지 왔다면, 서비스가 존재하며 이 서비스가 파드를 선택하고 있는 것이다. +파드 자체에 대해서는 이 연습의 시작부분에서 확인했었다. +이제 파드가 실제로 작동하는지 다시 확인해 보자. +위에서 나열된 엔드포인트를 이용하여 +서비스 메카니즘을 우회하고 파드에 직접 접근할 수 있다. + +{{< note >}} +이러한 명령은 서비스 포트(80)가 아닌 파드 포트(9376)을 사용한다. +{{< /note >}} + +파드 내에서 다음을 실행한다. + +```shell +for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do + wget -qO- $ep +done +``` + +이렇게 하면 다음과 같은 결과가 나타난다. + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + +엔드포인트 목록의 각 파드가 호스트네임을 반환할 것이라고 예상할 수 있다. +파드가 호스트네임을 반환하지 않는다면 (또는 파드가 정상 동작을 하지 않는다면) +무슨 일이 일어나고 있는지 조사해야 한다. + +## kube-proxy가 작동하는가? + +여기까지 진행했다면, 서비스가 실행 중이고, 엔드포인트가 있으며, 파드가 +실제로 서빙하고 있는 것이다. 이 시점에서는, 전체 서비스 프록시 메커니즘이 의심된다. +하나씩 확인하기로 한다. + +kube-proxy는 쿠버네티스 서비스의 기본 구현이며 대부분의 클러스터에서 사용하고 있다. +kube-proxy는 모든 노드에서 실행되며, 서비스 추상화를 제공하기 위한 +메커니즘 일부를 구성하는 프로그램이다. +사용자의 클러스터에서 kube-proxy를 사용하지 않는 경우, 다음 섹션이 적용되지 않으며, +사용 중인 서비스 구현에 대한 내용을 조사해야 할 것이다. + +### kube-proxy가 실행 중인가? + +노드에서 `kube-proxy`가 실행 중인지 확인한다. 다음의 명령을 노드에서 직접 실행하면, +아래와 같은 결과를 얻을 수 있다. + +```shell +ps auxw | grep kube-proxy +``` +```none +root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 +``` + +다음으로, 반드시 되어야 하는 것(예: 마스터와 통신)이 잘 되는지를 확인한다. +이를 수행하려면, 로그를 확인한다. 로그에 액세스하는 방법은 +노드의 OS 별로 다르다. 일부 OS에서는 /var/log/kube-proxy.log와 같은 파일이다. +반면 어떤 OS에서는 로그에 액세스하기 위해 `journalctl`을 사용한다. +다음과 같은 내용이 표시될 것이다. + +```none +I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" +I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier. +I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53] +I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53] +I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443] +I1027 22:14:54.038238 5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master +I1027 22:14:54.040048 5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP +I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP +I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP +``` + +마스터와 통신할 수 없다는 오류 메시지가 표시되면 +노드 구성 및 설치 단계를 다시 확인해야 한다. + +`kube-proxy`가 올바르게 실행되지 않는 이유 중 하나로 +필수 `conntrack` 바이너리를 찾을 수 없는 경우가 있을 수 있다. +클러스터를 설치하는 방법(예, 사전에 준비 없이 쿠버네티스를 설치)에 따라 +일부 리눅스 시스템에서 발생할 수 있다. 이 경우, +`conntrack` 패키지를 수동으로 설치(예: 우분투에서 `sudo apt install conntrack`)한 다음 +다시 시도해야 한다. + +Kube-proxy는 몇 가지 모드 중 하나로 실행할 수 있다. 위에 나열된 로그에서, +`Using iptables Proxier` 라인은 kube-proxy가 "iptables" 모드로 실행 중임을 나타낸다. +가장 일반적인 다른 모드는 "ipvs"이다. + +#### Iptables 모드 + +"iptables" 모드일 때, 노드에서 다음 명령을 실행하면 아래와 같은 내용이 표시될 것이다. + +```shell +iptables-save | grep hostnames +``` +```none +-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 +-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 +-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR +``` + +각 서비스의 포트에 대해, `KUBE-SERVICES` 내의 하나의 규칙, 그리고 +하나의 `KUBE-SVC-` 체인이 있어야 한다. 각 파드 엔드포인트에 대해, +해당 `KUBE-SVC-`에는 몇 개의 규칙이 있어야 하고, 또한 몇 개의 규칙을 포함하는 하나의 +`KUBE-SEP-` 체인이 있어야 한다. 정확한 규칙은 +사용자의 정확한 설정(노드 포트 및 로드 밸런서 포함)에 따라 다르다. + +#### IPVS 모드 + +"ipvs" 모드일 때, 노드에서 다음 명령을 실행하면 아래와 같은 내용이 표시될 것이다. + +```shell +ipvsadm -ln +``` +```none +Prot LocalAddress:Port Scheduler Flags + -> RemoteAddress:Port Forward Weight ActiveConn InActConn +... +TCP 10.0.1.175:80 rr + -> 10.244.0.5:9376 Masq 1 0 0 + -> 10.244.0.6:9376 Masq 1 0 0 + -> 10.244.0.7:9376 Masq 1 0 0 +... +``` + +각 서비스의 포트와 모든 NodePort, 외부 IP +및 로드 밸런서 IP에 대해 kube-proxy는 가상 서버를 생성한다. +각 파드 엔드포인트에 대해, kube-proxy는 각 가상 서버에 대응되는 실제 서버를 생성한다. +예제에서, 'hostnames' 서비스(`10.0.1.175:80`)에는 3개의 엔드포인트(`10.244.0.5:9376`, +`10.244.0.6:9376`, `10.244.0.7:9376`)가 있다. + +### kube-proxy가 프록싱을 수행하고 있는가? + +위에서 소개한 사례 중 하나를 마주했다고 가정한다면, +노드 중 하나에서 다음을 실행하여 서비스에 IP로 다시 액세스해 본다. + +```shell +curl 10.0.1.175:80 +``` +```none +hostnames-632524106-bbpiw +``` + +그래도 실패한다면, `kube-proxy` 로그에서 다음과 같은 특정 라인을 확인한다. + +```none +Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376] +``` + +이러한 라인이 보이지 않으면, `-v` 플래그를 4로 설정하여 `kube-proxy`를 재시작한 다음 +로그를 다시 살펴본다. + +### 엣지 케이스: 파드가 서비스 IP를 통해 자신에게 도달하는 데 실패하는 경우 {#a-pod-fails-to-reach-itself-via-the-service-ip} + +이러한 일이 일어날 것 같지 않을 수도 있지만 실제로 일어나기도 하며, 정상적이라면 제대로 동작해야 한다. + +이러한 현상은 네트워크가 '헤어핀' 트래픽(클러스터 내부에서 U턴하는 트래픽)에 대해 제대로 구성되지 않은 경우에 발생할 수 있으며, +이는 주로 `kube-proxy`가 `iptables` 모드에서 실행되고 +파드가 브릿지 네트워크에 연결된 경우에 해당할 수 있다. +`kubelet`은 파드가 자신이 속한 서비스 VIP로 접근하는 경우 +서비스의 엔드포인트가 이 트래픽을 다시 서비스의 파드로 로드밸런싱하도록 하는 +'hairpin-mode` [플래그](/docs/reference/command-line-tools-reference/kubelet/)를 노출한다. +`hairpin-mode` 플래그는 `hairpin-veth` 또는 `promiscuous-bridge`로 설정되어야 한다. + +이 문제를 해결하기 위한 일반적인 단계는 다음과 같다. + +* `hairpin-mode`가 `hairpin-veth` 또는 `promiscuous-bridge`로 설정되어 있는지 확인한다. + 아래와 같은 내용이 표시되어야 한다. 아래 예시에서 `hairpin-mode`는 + `promiscuous-bridge`로 설정되어 있다. + +```shell +ps auxw | grep kubelet +``` +```none +root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 +``` + +* 실제로 적용되어 있는 `hairpin-mode`가 무엇인지 확인한다. 이를 확인하려면, kubelet 로그를 확인해야 한다. + 로그 액세스는 노드 OS에 따라 다르다. 일부 OS에서는 + /var/log/kubelet.log와 같은 파일인 반면 다른 OS에서는 `journalctl`을 + 사용하여 로그에 액세스한다. 실제로 적용되어 있는 hairpin 모드는 호환성으로 인해 `--hairpin-mode` 플래그와 + 일치하지 않을 수 있으므로 주의한다. kubelet.log에 `hairpin` 이라는 키워드가 포함된 + 로그 라인이 있는지 확인한다. 아래와 같이 + 실행 중인 헤어핀 모드를 나타내는 로그 라인이 있을 것이다. + +```none +I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" +``` + +* 실행 중인 hairpin 모드가 `hairpin-veth`인 경우, `kubelet`이 +노드의 `/sys`에서 작동할 수 있는 권한이 있는지 확인한다. 모든 것이 제대로 작동한다면, +다음 명령을 실행했을 때 아래와 같이 표시될 것이다. + +```shell +for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done +``` +```none +1 +1 +1 +1 +``` + +* 실행 중인 hairpin 모드가 `promiscuous-bridge`인 경우, +`Kubelet`이 노드 안에서 리눅스 브릿지를 조작할 수 있는 권한이 있는지 확인한다. `cbr0` 브릿지가 +사용되었고 제대로 구성되어 있다면, 다음 명령을 실행했을 때 아래와 같이 표시될 것이다. + +```shell +ifconfig cbr0 |grep PROMISC +``` +```none +UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 +``` + +* 위의 방법 중 어느 것으로도 해결되지 않는다면, 도움을 요청한다. + +## 도움 요청하기 + +여기까지 왔다면, 아주 이상한 일이 발생하고 있는 것이다. 서비스가 +실행 중이고, 엔드포인트가 있으며, 파드가 실제로 서빙하고 있는 상태이다. +DNS가 작동 중이고, `kube-proxy`가 오작동하는 것은 아닌 것 같다. +그럼에도 서비스가 동작하지 않는 것이다. +우리가 도울 수 있도록, 어떤 일이 일어나고 있는지 커뮤니티에 알려주세요! + +[Slack](https://slack.k8s.io/) 또는 +[포럼](https://discuss.kubernetes.io) 또는 +[GitHub](https://github.com/kubernetes/kubernetes) +에 문의한다. + +## {{% heading "whatsnext" %}} + +자세한 내용은 [트러블슈팅하기 개요 문서](/ko/docs/tasks/debug/) +를 참고한다. From e408acb612091fbb709c0410bf54055c6b81135c Mon Sep 17 00:00:00 2001 From: "H.S.Lee (leehs1)" Date: Tue, 11 Apr 2023 17:12:20 +0900 Subject: [PATCH 44/69] [ko] Translate pod-security-admission.md into Korean Co-authored-by: Seokho Son --- .../security/pod-security-admission.md | 134 ++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 content/ko/docs/concepts/security/pod-security-admission.md diff --git a/content/ko/docs/concepts/security/pod-security-admission.md b/content/ko/docs/concepts/security/pod-security-admission.md new file mode 100644 index 0000000000..2a75c59b1c --- /dev/null +++ b/content/ko/docs/concepts/security/pod-security-admission.md @@ -0,0 +1,134 @@ +--- +# reviewers: +# - tallclair +# - liggitt +title: 파드 시큐리티 어드미션 +description: > + 파드 보안을 적용할 수 있는 파드 시큐리티 어드미션 컨트롤러에 대한 + 개요 +content_type: concept +weight: 20 +--- + + + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +쿠버네티스 [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)는 +파드에 대해 서로 다른 격리 수준을 정의한다. 이러한 표준을 사용하면 파드의 동작을 +명확하고 일관된 방식으로 제한하는 방법을 정의할 수 있다. + +쿠버네티스는 파드 시큐리티 스탠다드를 적용하기 위해 내장된 _파드 시큐리티_ +{{< glossary_tooltip text="어드미션 컨트롤러" term_id="admission-controller" >}}를 제공한다. 파드 시큐리티의 제한은 +파드가 생성될 때 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}} 수준에서 +적용된다. + +### 내장된 파드 시큐리티 어드미션 적용 + +이 페이지는 쿠버네티스 v{{< skew currentVersion >}}에 대한 문서 일부이다. +다른 버전의 쿠버네티스를 실행 중인 경우, 해당 릴리즈에 대한 문서를 참고한다. + + + +## 파드 시큐리티 수준 + +파드 시큐리티 어드미션은 파드의 +[시큐리티 컨텍스트](/docs/tasks/configure-pod-container/security-context/) 및 기타 관련 필드인 +[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards)에 정의된 세가지 수준에 따라 요구사항을 적용한다: +`특권(privileged)`, `기본(baseline)` 그리고 `제한(restricted)`. +이러한 요구사항에 대한 자세한 내용은 +[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards) 페이지를 참고한다. + +## 네임스페이스에 대한 파드 시큐리티 어드미션 레이블 + +이 기능이 활성화되거나 웹훅이 설치되면, 네임스페이스를 구성하여 +각 네임스페이스에서 파드 보안에 사용할 어드미션 제어 모드를 정의할 수 있다. +쿠버네티스는 미리 정의된 파드 시큐리티 스탠다드 수준을 사용자가 네임스페이스에 정의하여 +사용할 수 있도록 {{< glossary_tooltip term_id="label" text="레이블" >}} 집합을 정의한다. +선택한 레이블은 잠재적인 위반이 감지될 경우 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 +취하는 조치를 정의한다. + +{{< table caption="파드 시큐리티 어드미션 모드" >}} +모드 | 설명 +:---------|:------------ +**강제(enforce)** | 정책 위반 시 파드가 거부된다. +**감사(audit)** | 정책 위반이 [감사 로그](/ko/docs/tasks/debug/debug-cluster/audit/)에 감사 어노테이션 이벤트로 추가되지만, 허용은 된다. +**경고(warn)** | 정책 위반이 사용자에게 드러나도록 경고를 트리거하지만, 허용은 된다. +{{< /table >}} + +네임스페이스는 일부 또는 모든 모드를 구성하거나, 모드마다 다른 수준을 설정할 수 있다. + +각 모드에는, 사용되는 정책을 결정하는 두 개의 레이블이 존재한다. + +```yaml +# 모드별 단계 레이블은 모드에 적용할 정책 수준을 나타낸다. +# +# 모드(MODE)는 반드시 `강제(enforce)`, `감사(audit)` 혹은 `경고(warn)`중 하나여야 한다. +# 단계(LEVEL)는 반드시 `특권(privileged)`, `기본(baseline)`, or `제한(restricted)` 중 하나여야 한다. +pod-security.kubernetes.io/: + +# 선택 사항: 특정 쿠버네티스 마이너 버전(예를 들어, v{{< skew currentVersion >}})과 함께 +# 제공된 버전에 정책을 고정하는 데 사용할 수 있는 모드별 버전 레이블 +# +# 모드(MODE)는 반드시 `강제(enforce)`, `감사(audit)` 혹은 `경고(warn)`중 하나여야 한다. +# 버전(VERSION)은 반드시 올바른 쿠버네티스의 마이너(minor) 버전 혹은 '최신(latest)'하나여야 한다. +pod-security.kubernetes.io/-version: +``` + +[네임스페이스 레이블로 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) 문서를 확인하여 사용 예시를 확인한다. + +## 워크로드 리소스 및 파드 템플릿 + +파드는 {{< glossary_tooltip term_id="deployment" >}}나 {{< glossary_tooltip term_id="job">}}과 같은 +[워크로드 오브젝트](/ko/docs/concepts/workloads/controllers/) 생성을 통해 +간접적으로 생성되는 경우가 많다. 워크로드 오브젝트는 _파드 템플릿_을 정의하고 +워크로드 리소스에 대한 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 +해당 템플릿을 기반으로 파드를 생성한다. 위반을 조기에 발견할 수 있도록 감사 모드와 경고 모드가 +모두 워크로드 리소스에 적용된다. 그러나 강제 모드에서는 워크로드 리소스에 +적용되지 **않으며**, 결과가 되는 파드 오브젝트에만 적용된다. + +## 면제 (exemptions) + +지정된 네임스페이스와 관련된 정책으로 인해 금지된 +파드 생성을 허용하기 위해 파드 보안 강제에서 _면제_ 를 정의할 수 있다. +면제는 [어드미션 컨트롤러 구성하기](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller) +에서 정적으로 구성할 수 있다. + +면제는 명시적으로 열거해야 한다. 면제 기준을 충족하는 요청은 +어드미션 컨트롤러에 의해 _무시_ 된다. 면제 기준은 다음과 같다. + +- **사용자 이름(Usernames):** 면제 인증된(혹은 사칭한) 사용자 이름을 가진 사용자의 요청은 + 무시된다. +- **런타임 클래스 이름(RuntimeClassNames):** 면제 런타임 클래스 이름을 지정하는 파드 및 [워크로드 리소스](#워크로드-리소스-및-파드-템플릿)는 + 무시된다. +- **네임스페이스(Namespaces):** 파드 및 [워크로드 리소스](#워크로드-리소스-및-파드-템플릿)는 면제 네임스페이스에서 무시된다. + +{{< caution >}} + +대부분의 파드는 컨트롤러가 [워크로드 리소스](#워크로드-리소스-및-파드-템플릿) +에 대한 응답으로 생성되므로, 최종 사용자가 파드를 직접 생성할 때만 +적용을 면제하고 워크로드 리소스를 생성할 때는 적용이 면제하지 않는다. +컨트롤러 서비스 어카운트(예로 `system:serviceaccount:kube-system:replicaset-controller`) +는 일반적으로 해당 워크로드 리소스를 생성할 수 있는 모든 사용자를 암시적으로 +면제할 수 있으므로 면제해서는 안 된다. + +{{< /caution >}} + +다음 파드 필드에 대한 업데이트는 정책 검사에서 제외되므로, 파드 업데이트 요청이 +이러한 필드만 변경하는 경우, 파드가 현재 정책 수준을 위반하더라도 +거부되지 않는다. + +- seccomp 또는 AppArmor 어노테이션에 대한 변경 사항을 **제외한** 모든 메타데이터 업데이트. + - `seccomp.security.alpha.kubernetes.io/pod` (사용 중단) + - `container.seccomp.security.alpha.kubernetes.io/*` (사용 중단) + - `container.apparmor.security.beta.kubernetes.io/*` +- `.spec.activeDeadlineSeconds` 에 대해 유효한 업데이트 +- `.spec.tolerations` 에 대해 유효한 업데이트 + +## {{% heading "whatsnext" %}} + +- [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards) +- [파드 시큐리티 스탠다드 적용하기](/ko/docs/setup/best-practices/enforcing-pod-security-standards) +- [기본 제공 어드미션 컨트롤러를 구성하여 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-admission-controller) +- [네임스페이스 레이블로 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) +- [파드시큐리티폴리시(PodSecurityPolicy)에서 내장 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp) From 5cc285f781a5cd466ddfe3355d94f5eb71007ae7 Mon Sep 17 00:00:00 2001 From: namuk2004 Date: Wed, 3 May 2023 07:31:29 +0900 Subject: [PATCH 45/69] [ko] Update outdated files in dev-1.26.-ko.1 [M149-155] Update outdated files in dev-1.26.-ko.1 [M149-155] --- .../administer-cluster/cluster-upgrade.md | 12 +- .../dns-custom-nameservers.md | 169 ++++++------------ .../kubeadm/kubeadm-upgrade.md | 8 +- .../memory-default-namespace.md | 8 + .../cilium-network-policy.md | 55 +++--- .../use-cascading-deletion.md | 142 +-------------- .../managing-secret-using-config-file.md | 56 +++++- 7 files changed, 162 insertions(+), 288 deletions(-) diff --git a/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md b/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md index 14fec25606..972c36c08f 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-upgrade.md @@ -89,4 +89,14 @@ content_type: task kubectl convert -f pod.yaml --output-version v1 ``` -`kubectl` 도구는 `pod.yaml`의 내용을 `kind`를 파드(변경되지 않음, unchanged)로 설정하는 매니페스트로 대체하고, 수정된 `apiVersion`으로 대체한다. +`kubectl` 도구는 `pod.yaml`의 내용을 `kind`를 파드(변경되지 않음, unchanged)로 설정하는 매니페스트로 대체하고, +수정된 `apiVersion`으로 대체한다. + +### 장치 플러그인 + +클러스터가 장치 플러그인을 실행 중이고 노드를 최신 장치 플러그인 API 버전이 있는 +쿠버네티스 릴리스로 업그레이드해야 하는 경우, +업그레이드 중에 장치 할당이 계속 성공적으로 완료되도록 하려면 +장치 플러그인을 업그레이드해야 한다. + +[API 호환성](docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md/#api-compatibility) 및 [Kubelet 장치 매니저 API 버전](docs/reference/node/device-plugin-api-versions.md)을 참조한다. 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 3585127c97..b88cfa4c9b 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -17,8 +17,6 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한 {{< include "task-tutorial-prereqs.md" >}} 클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. -[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기) -는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다. {{% version-check %}} @@ -27,25 +25,27 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한 ## 소개 DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을 -사용하여 자동으로 시작되는 쿠버네티스 -내장 서비스이다. - -쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, -CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다. +사용하여 자동으로 시작되는 쿠버네티스 내장 서비스이다. {{< note >}} CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. -이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. +그 의도는 기존의 `kube-dns` 서비스 이름을 사용하여 +클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. +`kube-dns` 로 서비스 이름을 사용하면, +해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. {{< /note >}} -CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. -Kubelet 은 `--cluster-dns=` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다. +CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, +일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. +Kubelet 은 `--cluster-dns=` 플래그를 사용하여 +DNS 확인자 정보를 각 컨테이너에 전달한다. DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=` 플래그를 통하여 로컬 도메인을 설정할 수 있다. -DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. -더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다. +DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), +역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. 더 자세한 내용은 +[서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다. 만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, 파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다. @@ -59,15 +59,16 @@ DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유 ## CoreDNS -CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다. +CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 +클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다. ### CoreDNS 컨피그맵(ConfigMap) 옵션 CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다. -이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다. -클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여 -해당 클러스터에 대한 DNS 서비스 검색 동작을 -변경할 수 있다. +CoreDNS 서버는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 +관리하여 구성할 수 있다. 클러스터 관리자는 CoreDNS Corefile에 대한 +{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여 +해당 클러스터에 대한 DNS 서비스 검색 동작을 변경할 수 있다. 쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다. @@ -102,35 +103,57 @@ data: Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다. * [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다. -* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다. -* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다. -* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다. - `pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다. -* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다. -* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다. +* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 + `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 + 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다. +* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, + 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다. +* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 + 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. + 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. + - `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. + 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. + 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다. + - `pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. + - `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 + A 레코드를 반환하게 할 수 있다. + - `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다. +* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 + [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 + `http://localhost:9153/metrics` 에서 사용 가능하다. +* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 + 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다. * [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다. -* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다. -* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다. -* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다. +* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, + 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다. +* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. + 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다. +* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, + AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다. 사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다. ### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정 -CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다. +CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 +스텁 도메인 및 업스트림 네임서버를 구성할 수 있다. #### 예시 -만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다. + +만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, +모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 +클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다. ``` consul.local:53 { - errors - cache 30 - forward . 10.150.0.1 - } + errors + cache 30 + forward . 10.150.0.1 +} ``` -모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다. +모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, +`/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다. ``` forward . 172.16.0.1 @@ -167,88 +190,12 @@ data: } ``` -`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 -자동 변환을 지원한다. - {{< note >}} -kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다. +CoreDNS는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 지원하지 않는다. 변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다. {{< /note >}} -## kube-dns에 대응되는 CoreDNS 설정 - -CoreDNS는 kube-dns 이상의 기능을 지원한다. -`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다. - -### 예시 - -kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다. - -```yaml -apiVersion: v1 -data: - stubDomains: | - {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} - upstreamNameservers: | - ["8.8.8.8", "8.8.4.4"] -kind: ConfigMap -``` - -CoreDNS에서는 동등한 설정으로 Corefile을 생성한다. - -* stubDomains 에 대응하는 설정: -```yaml -abc.com:53 { - errors - cache 30 - forward . 1.2.3.4 -} -my.cluster.local:53 { - errors - cache 30 - forward . 2.3.4.5 -} -``` - -기본 플러그인으로 구성된 완전한 Corefile. - -``` -.:53 { - errors - health - kubernetes cluster.local in-addr.arpa ip6.arpa { - pods insecure - fallthrough in-addr.arpa ip6.arpa - } - federation cluster.local { - foo foo.feddomain.com - } - prometheus :9153 - forward . 8.8.8.8 8.8.4.4 - cache 30 -} -abc.com:53 { - errors - cache 30 - forward . 1.2.3.4 -} -my.cluster.local:53 { - errors - cache 30 - forward . 2.3.4.5 -} -``` - -## CoreDNS로의 이관 - -kube-dns에서 CoreDNS로 이관하기 위하여, -kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는 -[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다. - -또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 -사용하여 이관할 수도 있다. - - ## {{% heading "whatsnext" %}} - [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기 + diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 0dfe0865d6..5143c80379 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -208,8 +208,8 @@ sudo kubeadm upgrade apply - 노드를 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 전환한다. ```shell - # 을 드레인하려는 노드의 이름으로 바꾼다. - kubectl uncordon + # 을 드레인하려는 노드의 이름으로 바꾼다. + kubectl uncordon ``` ## 워커 노드 업그레이드 @@ -289,8 +289,8 @@ sudo kubeadm upgrade apply - 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다. ```shell - # 을 노드의 이름으로 바꾼다. - kubectl uncordon + # 을 노드의 이름으로 바꾼다. + kubectl uncordon ``` ## 클러스터 상태 확인 diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index ad6885313e..8b36c28afc 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -167,6 +167,14 @@ resources: memory: 128Mi ``` +{{< note >}} + +`리밋레인지`는 적용되는 기본 값의 일관성을 검사하지 않는다. 이는 `리밋레인지`에 의해 설정된 _상한_의 기본값이 클라이언트가 API 서버에 제출하는 사양의 컨테이너에 대해 지정된 _요청량_ 값보다 작을 수 있음을 의미한다. 이 경우, 최종 파드는 스케줄링할 수 없다. +자세한 내용은 [리밋 레인지 개요](/docs/concepts/policy/limit-range/#constraints-on-resource-limits-and-requests)를 참조한다. + +{{< /note >}} + + ## 기본 메모리 상한 및 요청량에 대한 동기 네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가 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 426aeda7f2..a112f71f25 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 @@ -41,44 +41,39 @@ minikube version: v1.5.2 minikube start --network-plugin=cni ``` -minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다. -실리움은 클러스터 구성을 자동으로 감지하고 -성공적인 설치를 위해 적절한 구성 요소를 설치한다. +minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다. 그러기 위해서, +먼저 다음과 같은 명령을 사용하여 최신 버전의 CLI를 다운로드 한다. ```shell curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz +``` + +이후 다음과 같은 명령을 사용하여 다운받은 파일을 `/usr/local/bin` 디렉토리에 압축을 푼다. + +```shell sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin rm cilium-linux-amd64.tar.gz +``` + +위의 명령을 실행한 후, 이제 다음 명령으로 실리움(Cilium)을 설치할 수 있다. + +```shell cilium install ``` -```shell -🔮 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... -``` +그런 다음 실리움은 자동으로 클러스터를 구성을 감지하고 +성공적인 설치를 위해 적절한 구성요소를 만들고 설치한다. +구성요소는 다음과 같다. + +- 시크릿 `cilium-ca`의 인증 기관(CA) 및 Hubble (실리움의 관측 가능성 계층)에 대한 인증서. +- 서비스 어카운트. +- 클러스터 롤. +- 컨피그맵. +- 에이전트 데몬셋 및 오퍼레이터 디플로이먼트. + +설치 후, `cilium status` 명령으로 실리움 디플로이먼트의 전체 상태를 볼 수 있다. +`status` 명령으로 예상 출력을 참조한다. +[여기](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#validate-the-installation). 시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여 L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, HTTP)의 보안 정책을 diff --git a/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md b/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md index 2e44d61f64..fdb9b9c3a0 100644 --- a/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md +++ b/content/ko/docs/tasks/administer-cluster/use-cascading-deletion.md @@ -47,8 +47,7 @@ apiVersion: v1 `kubectl` 또는 쿠버네티스 API를 사용해 포그라운드 캐스케이딩 삭제로 전환할 수 있다. {{}} -{{}} -{{% tab name="쿠버네티스 1.20.x 이후 버전" %}} + `kubectl` 또는 쿠버네티스 API를 사용해 포그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다. @@ -96,47 +95,6 @@ kubectl delete deployment nginx-deployment --cascade=foreground ... ``` -{{% /tab %}} -{{% tab name="쿠버네티스 1.20.x 전 버전" %}} -쿠버네티스 API를 사용해 -포그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다. - -상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다. - -1. 로컬 프록시 세션을 시작한다. - - ```shell - kubectl proxy --port=8080 - ``` - -1. 삭제를 작동시키기 위해 `curl`을 사용한다. - - ```shell - curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ - -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ - -H "Content-Type: application/json" - ``` - - 출력에는 다음과 같이 - `foregroundDeletion` {{}}가 포함되어 있다. - - ``` - "kind": "Deployment", - "apiVersion": "apps/v1", - "metadata": { - "name": "nginx-deployment", - "namespace": "default", - "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505", - "resourceVersion": "1363097", - "creationTimestamp": "2021-07-08T20:24:37Z", - "deletionTimestamp": "2021-07-08T20:27:39Z", - "finalizers": [ - "foregroundDeletion" - ] - ... - ``` -{{% /tab %}} -{{}} ## 백그라운드 캐스케이딩 삭제 사용 {#use-background-cascading-deletion} @@ -144,8 +102,6 @@ kubectl delete deployment nginx-deployment --cascade=foreground 1. 클러스터를 실행하는 쿠버네티스 버전에 따라 디플로이먼트를 삭제하기 위해 `kubectl` 또는 쿠버네티스 API를 사용한다. {{}} -{{}} -{{% tab name="쿠버네티스 1.20.x 이후 버전" %}} `kubectl` 또는 쿠버네티스 API를 사용해 백그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다. @@ -192,54 +148,6 @@ kubectl delete deployment nginx-deployment --cascade=background "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456" } ``` -{{% /tab %}} -{{% tab name="쿠버네티스 1.20.x 전 버전" %}} -쿠버네티스는 기본적으로 백그라운드 캐스케이딩 삭제를 사용하므로, `--cascade` 플래그 -또는 `propagationPolicy: Background` 인수 없이 -다음 명령을 실행해도 같은 작업을 수행한다. - -상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다. - -**kubectl 사용** - -다음 명령어를 실행한다. - -```shell -kubectl delete deployment nginx-deployment --cascade=true -``` - -**쿠버네티스 API 사용** - -1. 로컬 프록시 세션을 시작한다. - - ```shell - kubectl proxy --port=8080 - ``` - -1. 삭제를 작동시키기 위해 `curl`을 사용한다. - - ```shell - curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ - -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ - -H "Content-Type: application/json" - ``` - - 출력은 다음과 유사하다. - - ``` - "kind": "Status", - "apiVersion": "v1", - ... - "status": "Success", - "details": { - "name": "nginx-deployment", - "group": "apps", - "kind": "deployments", - "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456" - } - ``` -{{% /tab %}} -{{}} ## 소유자 오브젝트 및 종속된 고아(orphan) 오브젝트 삭제 {#set-orphan-deletion-policy} @@ -250,8 +158,6 @@ kubectl delete deployment nginx-deployment --cascade=true 쿠버네티스 버전에 따라 `kubectl` 또는 쿠버네티스 API를 사용해 종속 오브젝트를 쿠버네티스 *고아*로 만들 수 있다. {{}} -{{}} -{{% tab name="쿠버네티스 1.20.x 이후 버전" %}} **kubectl 사용** @@ -293,52 +199,6 @@ kubectl delete deployment nginx-deployment --cascade=orphan ... ``` -{{% /tab %}} -{{% tab name="쿠버네티스 1.20.x 전 버전" %}} - -상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다. - -**kubectl 사용** - -다음 명령어를 실행한다. - -```shell -kubectl delete deployment nginx-deployment --cascade=orphan -``` - -**쿠버네티스 API 사용** - -1. 로컬 프록시 세션을 시작한다. - - ```shell - kubectl proxy --port=8080 - ``` - -1. 삭제를 작동시키기 위해 `curl`을 사용한다. - - ```shell - curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ - -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ - -H "Content-Type: application/json" - ``` - - 출력에는 다음과 같이 `finalizers` 필드에 `orphan`이 포함되어 있다. - - ``` - "kind": "Deployment", - "apiVersion": "apps/v1", - "namespace": "default", - "uid": "6f577034-42a0-479d-be21-78018c466f1f", - "creationTimestamp": "2021-07-09T16:46:37Z", - "deletionTimestamp": "2021-07-09T16:47:08Z", - "deletionGracePeriodSeconds": 0, - "finalizers": [ - "orphan" - ], - ... - ``` -{{% /tab %}} -{{}} 디플로이먼트가 관리하는 파드들이 계속 실행 중인지 확인할 수 있다. diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md index 2c38246834..2b1b6ce9ba 100644 --- a/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -170,6 +170,61 @@ type: Opaque `YWRtaW5pc3RyYXRvcg==`는 `administrator`으로 디코딩된다. +## 시크릿(Secret) 작성 {#edit-secret} + +매니페스트를 사용하여 생성한 시크릿의 데이터를 편집하려면, 매니페스트에서 `data` +및 `stringData` 필드를 수정하고 해당 파일을 클러스터에 적용하면 된다. +그렇지 않은 경우 기존의 `시크릿` 오브젝트를 편집할 수 있다. +[수정 불가능한(immutable)](/docs/concepts/configuration/secret/#secret-immutable). + +예를 들어, 이전 예제에서 패스워드를 `birdsarentreal`로 변경하려면, +다음과 같이 수행한다. + +1. 새로운 암호 문자열을 인코딩한다. + + ```shell + echo -n 'birdsarentreal' | base64 + ``` + + 출력은 다음과 같다. + + ``` + YmlyZHNhcmVudHJlYWw= + ``` + +1. 새 암호 문자열로 `data` 필드를 업데이트 한다. + + ```yaml + apiVersion: v1 + kind: Secret + metadata: + name: mysecret + type: Opaque + data: + username: YWRtaW4= + password: YmlyZHNhcmVudHJlYWw= + ``` + +1. 클러스터에 매니페스트를 적용한다. + + ```shell + kubectl apply -f ./secret.yaml + ``` + + 출력은 다음과 같다. + + ``` + secret/mysecret configured + ``` + +쿠버네티스는 기존 `시크릿` 오브젝트를 업데이트한다. 자세히 보면, `kubectl` 도구는 +동일한 이름을 가진 기존 `Secret` 오브젝트가 있음을 알아낸다. +`kubectl`은 기존의 오브젝트를 가져오고, 변경을 계획하며, +변경된 `Secret` 오브젝트를 클러스터 컨트롤 플레인에 제출한다. + +`kubectl apply --server-side`를 지정한 경우, `kubectl`은 +[서버 사이드 어플라이](/docs/reference/using-api/server-side-apply/)를 대신 사용한다. + ## 삭제 생성한 시크릿을 삭제하려면 다음 명령을 실행한다. @@ -183,4 +238,3 @@ kubectl delete secret mysecret - [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기 - [kubectl을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 알아보기 - [kustomize를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 알아보기 - From a3997bdc2078b121adf2f4a3f3981d27f341b5b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Tue, 9 May 2023 16:20:00 +0900 Subject: [PATCH 46/69] Update outdated korean contents in dev-1.26-ko.1 (M163) --- .../determine-reason-pod-failure.md | 91 +++++++++---------- 1 file changed, 45 insertions(+), 46 deletions(-) diff --git a/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md index 0ab055bc71..d0e0a53640 100644 --- a/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure.md @@ -1,81 +1,83 @@ --- title: 파드 실패의 원인 검증하기 content_type: task +weight: 30 --- -이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 -방법을 보여준다. +이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 방법을 보여준다. 종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를, 대시보드나 모니터링 소프트웨어 도구와 같이 쉽게 조회 및 표시할 수 있는 위치에 기록하는 방법을 제공한다. 대부분의 경우에 종료 메시지에 넣는 정보는 -일반 +일반적으로 [쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다. - - - ## {{% heading "prerequisites" %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - +{{< include "task-tutorial-prereqs.md" >}} ## 종료 메시지 읽기 및 쓰기 이 예제에서는, 하나의 컨테이너를 실행하는 파드를 생성한다. -하단의 설정 파일은 컨테이너가 시작될 때 수행하는 -명령어를 지정한다. +파드의 매니페스트는 컨테이너가 시작될 때 수행하는 명령어를 지정한다. {{< codenew file="debug/termination.yaml" >}} 1. 다음의 YAML 설정 파일에 기반한 파드를 생성한다. - kubectl apply -f https://k8s.io/examples/debug/termination.yaml + ```shell + kubectl apply -f https://k8s.io/examples/debug/termination.yaml + ``` - YAML 파일에 있는 `command` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 - "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 - 것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를 - 기록한 후에 종료된다. + YAML 파일에 있는 `command` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 + "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 + 것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를 + 기록한 후에 종료된다. 1. 파드와 관련된 정보를 출력한다. - kubectl get pod termination-demo + ```shell + kubectl get pod termination-demo + ``` - 파드가 더 이상 실행되지 않을 때까지 앞선 명령어를 반복한다. + 파드가 더 이상 실행되지 않을 때까지 앞선 명령어를 반복한다. 1. 파드에 관한 상세 정보를 출력한다. - kubectl get pod termination-demo --output=yaml + ```shell + kubectl get pod termination-demo --output=yaml + ``` - 결과는 "Sleep expired" 메시지를 포함한다. + 결과는 "Sleep expired" 메시지를 포함한다. - apiVersion: v1 - kind: Pod - ... - lastState: - terminated: - containerID: ... - exitCode: 0 - finishedAt: ... - message: | - Sleep expired - ... + ```yaml + apiVersion: v1 + kind: Pod + ... + lastState: + terminated: + containerID: ... + exitCode: 0 + finishedAt: ... + message: | + Sleep expired + ... + ``` -1. 종료 메시지만을 포함하는 출력 결과를 보기 -위해서는 Go 템플릿을 사용한다. +1. 종료 메시지만을 포함하는 출력 결과를 보기 위해서는 Go 템플릿을 사용한다. - kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" + ```shell + kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" + ``` -여러 컨테이너를 포함하는 파드의 경우, Go 템플릿을 사용하여 컨테이너 이름도 출력할 수 있다. 이렇게 하여, 어떤 컨테이너가 실패하는지 찾을 수 있다. +여러 컨테이너를 포함하는 파드의 경우, Go 템플릿을 사용하여 컨테이너 이름도 출력할 수 있다. +이렇게 하여, 어떤 컨테이너가 실패하는지 찾을 수 있다. ```shell kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:\n%s\n\n" .name .lastState.terminated.message}}{{end}}' @@ -90,9 +92,9 @@ kubectl get pod multi-container-pod -o go-template='{{range .status.containerSta 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다. 종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다. -kubelet은 4096 바이트보다 긴 메시지를 자른다. +kubelet은 4096 바이트보다 긴 메시지를 자른다. -모든 컨테이너의 총 메시지 길이는 12KiB로 제한되며, 각 컨테이너에 균등하게 분할된다. +모든 컨테이너의 총 메시지 길이는 12KiB로 제한되며, 각 컨테이너에 균등하게 분할된다. 예를 들어, 12개의 컨테이너(`initContainers` 또는 `containers`)가 있는 경우 각 컨테이너에는 1024 바이트의 사용 가능한 종료 메시지 공간이 있다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. @@ -121,12 +123,9 @@ spec: 쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. 로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다. - - ## {{% heading "whatsnext" %}} - -* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - 에 있는 `terminationMessagePath` 에 대해 읽어보기. -* [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기. -* [Go 템플릿](https://pkg.go.dev/text/template)에 대해 배워보기. +- [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) + 에 있는 `terminationMessagePath` 필드에 대해 읽어보기. +- [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기. +- [Go 템플릿](https://pkg.go.dev/text/template/)에 대해 배워보기. From 3ace4ab20efbd3f16c8b3ea2b1d5a282059cf2bc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Thu, 11 May 2023 02:54:10 +0900 Subject: [PATCH 47/69] [ko] Update outdated korean contents in dev-1.26-ko.1 (M156-M157) --- .../managing-secret-using-kubectl.md | 206 ++++++++++-------- .../managing-secret-using-kustomize.md | 141 ++++++------ 2 files changed, 181 insertions(+), 166 deletions(-) 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 4f83b5ea35..ab15d26dba 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 @@ -1,5 +1,5 @@ --- -title: kubectl을 사용한 시크릿 관리 +title: kubectl을 사용한 시크릿(Secret) 관리 content_type: task weight: 10 description: kubectl 커맨드를 사용하여 시크릿 오브젝트를 생성. @@ -7,6 +7,10 @@ description: kubectl 커맨드를 사용하여 시크릿 오브젝트를 생성. +이 페이지는 `kubectl` 커맨드라인 툴을 이용하여 쿠버네티스 +{{}}을 +생성, 편집, 관리, 삭제하는 방법을 보여준다. + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} @@ -15,64 +19,64 @@ description: kubectl 커맨드를 사용하여 시크릿 오브젝트를 생성. ## 시크릿 생성 -`시크릿`에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다. -예를 들어 데이터베이스 연결 문자열은 사용자 이름과 암호로 구성된다. -사용자 이름은 로컬 컴퓨터의 `./username.txt` 파일에, 비밀번호는 -`./password.txt` 파일에 저장할 수 있다. +`시크릿` 오브젝트는 파드가 서비스에 접근하기 위해 사용하는 자격 증명과 같은 +민감한 데이터를 저장한다. 예를 들어 데이터베이스에 접근하는데 필요한 사용자 이름과 비밀번호를 +저장하기 위해서 시크릿이 필요할 수 있다. -```shell -echo -n 'admin' > ./username.txt -echo -n '1f2d1e2e67df' > ./password.txt -``` -이 명령에서 `-n` 플래그는 생성된 파일의 -텍스트 끝에 추가 개행 문자가 포함되지 않도록 해 준다. 이는 `kubectl`이 파일을 읽고 -내용을 base64 문자열로 인코딩할 때 개행 문자도 함께 인코딩될 수 있기 때문에 -중요하다. +명령어를 통해 원시 데이터를 바로 보내거나, 파일에 자격 증명을 저장하고 명령어로 전달하는 방식으로 +시크릿을 생성할 수 있다. 다음 명령어는 사용자 이름을 `admin`으로 +비밀번호는 `S!B\*d$zDsb=`으로 저장하는 시크릿을 생성한다. -`kubectl create secret` 명령은 이러한 파일들을 시크릿으로 패키징하고 -API 서버에 오브젝트를 생성한다. +### 원시 데이터 사용 + +다음 명령어를 실행한다. ```shell kubectl create secret generic db-user-pass \ - --from-file=./username.txt \ - --from-file=./password.txt + --from-literal=username=admin \ + --from-literal=password='S!B\*d$zDsb=' ``` +문자열에서 `$`, `\`, `*`, `=` 및 `!`과 같은 특수 문자를 이스케이프(escape)하기 +위해서는 작은따옴표 `''`를 사용해야 한다. 그렇지 않으면 셸은 이런 문자들을 +해석한다. -출력은 다음과 유사하다. +### 소스 파일 사용 + +1. base64로 인코딩된 자격 증명의 값들을 파일에 저장한다. + + ```shell + echo -n 'admin' | base64 > ./username.txt + echo -n 'S!B\*d$zDsb=' | base64 > ./password.txt + ``` + `-n` 플래그는 생성된 파일이 텍스트 끝에 추가적인 개행 문자를 갖지 + 않도록 보장한다. 이는 `kubectl`이 파일을 읽고 내용을 base64 + 문자열로 인코딩할 때 개행 문자도 함께 인코딩될 수 있기 때문에 + 중요하다. 파일에 포함된 문자열에서 특수 문자를 이스케이프 할 + 필요는 없다. + +1. `kubectl` 명령어에 파일 경로를 전달한다. + + ```shell + kubectl create secret generic db-user-pass \ + --from-file=./username.txt \ + --from-file=./password.txt + ``` + 기본 키 이름은 파일 이름이다. 선택적으로 `--from-file=[key=]source`를 사용하여 + 키 이름을 설정할 수 있다. 예제: + + ```shell + kubectl create secret generic db-user-pass \ + --from-file=username=./username.txt \ + --from-file=password=./password.txt + ``` + +두 방법 모두 출력은 다음과 유사하다. ``` secret/db-user-pass created ``` -기본 키 이름은 파일 이름이다. 선택적으로 `--from-file=[key=]source`를 사용하여 키 이름을 설정할 수 있다. -예제: - -```shell -kubectl create secret generic db-user-pass \ - --from-file=username=./username.txt \ - --from-file=password=./password.txt -``` - -파일에 포함하는 암호 문자열에서 -특수 문자를 이스케이프하지 않아도 된다. - -`--from-literal==` 태그를 사용하여 시크릿 데이터를 제공할 수도 있다. -이 태그는 여러 키-값 쌍을 제공하기 위해 두 번 이상 지정할 수 있다. -`$`, `\`, `*`, `=` 및 `!`와 같은 특수 문자는 -[shell](https://en.wikipedia.org/wiki/Shell_(computing))에 해석하고 처리하기 때문에 -이스케이프할 필요가 있다. - -대부분의 셸에서 암호를 이스케이프하는 가장 쉬운 방법은 암호를 작은따옴표(`'`)로 둘러싸는 것이다. -예를 들어, 비밀번호가 `S!B\*d$zDsb=`인 경우, -다음 커맨드를 실행한다. - -```shell -kubectl create secret generic db-user-pass \ - --from-literal=username=devuser \ - --from-literal=password='S!B\*d$zDsb=' -``` - -## 시크릿 확인 +### 시크릿 확인 {#verify-the-secret} 시크릿이 생성되었는지 확인한다. @@ -83,14 +87,14 @@ kubectl get secrets 출력은 다음과 유사하다. ``` -NAME TYPE DATA AGE -db-user-pass Opaque 2 51s +NAME TYPE DATA AGE +db-user-pass Opaque 2 51s ``` -다음 명령을 실행하여 `시크릿`에 대한 상세 사항을 볼 수 있다. +시크릿의 상세 사항을 보자. ```shell -kubectl describe secrets/db-user-pass +kubectl describe secret db-user-pass ``` 출력은 다음과 유사하다. @@ -113,62 +117,86 @@ username: 5 bytes 기본적으로 `시크릿`의 내용을 표시하지 않는다. 이는 `시크릿`이 실수로 노출되거나 터미널 로그에 저장되는 것을 방지하기 위한 것이다. +### 시크릿 디코딩 {#decoding-secret} -인코딩된 데이터의 실제 내용을 확인하려면 [시크릿 디코딩](#decoding-secret)을 확인하자. +1. 생성한 시크릿을 보려면 다음 명령을 실행한다. -## 시크릿 디코딩 {#decoding-secret} + ```shell + kubectl get secret db-user-pass -o jsonpath='{.data}' + ``` -생성한 시크릿을 보려면 다음 명령을 실행한다. + 출력은 다음과 유사하다. + + ```json + { "password": "UyFCXCpkJHpEc2I9", "username": "YWRtaW4=" } + ``` + +1. `password` 데이터를 디코딩한다. + + ```shell + echo 'UyFCXCpkJHpEc2I9' | base64 --decode + ``` + + 출력은 다음과 유사하다. + + ``` + S!B\*d$zDsb= + ``` + + {{< caution >}} + 이 예시는 문서화를 위한 것이다. 실제로, + 이 방법은 인코딩된 데이터가 포함된 명령어를 셸 히스토리에 남기게 되는 문제를 야기할 수 있다. + 당신의 컴퓨터에 접근할 수 있는 사람은 누구나 그 명령어를 찾아 그 비밀 정보를 + 디코드할 수 있다. 더 나은 접근법은 시크릿을 보는 명령어와 디코드하는 명령어를 + 조합하여 사용하는 것이다. + {{< /caution >}} + + ```shell + kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode + ``` + +## 시크릿 편집 {#edit-secret} + +존재하는 `시크릿` 오브젝트가 [수정 불가능한(immutable)](/ko/docs/concepts/configuration/secret/#secret-immutable)이 +아니라면 편집할 수 있다. 시크릿을 편집하기 위해서 +다음 명령어를 실행한다. ```shell -kubectl get secret db-user-pass -o jsonpath='{.data}' +kubectl edit secrets ``` -출력은 다음과 유사하다. +이 명령어는 기본 편집기를 열고 다음 예시와 같이 `data` 필드의 base64로 인코딩된 +시크릿의 값들을 업데이트할 수 있도록 허용한다. -```json -{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="} +```yaml +# 아래 오브젝트를 편집하길 바란다. '#'로 시작하는 줄은 무시될 것이고, +# 빈 파일은 편집을 중단시킬 것이다. 이 파일을 저장하는 동안 오류가 발생한다면 +# 이 파일은 관련된 오류와 함께 다시 열린다. +# +apiVersion: v1 +data: + password: UyFCXCpkJHpEc2I9 + username: YWRtaW4= +kind: Secret +metadata: + creationTimestamp: "2022-06-28T17:44:13Z" + name: db-user-pass + namespace: default + resourceVersion: "12708504" + uid: 91becd59-78fa-4c85-823f-6d44436242ac +type: Opaque ``` -이제 `password` 데이터를 디코딩할 수 있다. - -```shell -# 이 예시는 문서화를 위한 것이다. -# 아래와 같은 방법으로 이를 수행했다면, -# 'MWYyZDFlMmU2N2Rm' 데이터가 셸 히스토리에 저장될 수 있다. -# 당신의 컴퓨터에 접근할 수 있는 사람이 당신 몰래 저장된 명령을 찾아 -# 시크릿을 base-64 디코드할 수도 있다. -# 따라서 이 페이지의 아래 부분에 나오는 다른 단계들과 조합하는 것이 좋다. -echo 'MWYyZDFlMmU2N2Rm' | base64 --decode -``` - -출력은 다음과 유사하다. - -``` -1f2d1e2e67df -``` - -인코딩된 시크릿 값이 셸 히스토리에 저장되는 것을 피하려면, -다음의 명령을 실행할 수 있다. - -```shell -kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode -``` - -출력은 위의 경우와 유사할 것이다. - ## 삭제 -생성한 시크릿을 삭제하려면 다음 명령을 실행한다. +시크릿을 삭제하기 위해서 다음 명령어를 실행한다. ```shell kubectl delete secret db-user-pass ``` - - ## {{% heading "whatsnext" %}} - [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기 - [환경 설정 파일을 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 알아보기 -- [kustomize를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 알아보기 +- [kustomize를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 알아보기 \ No newline at end of file diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md index 2198903885..e730892ae1 100644 --- a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -1,5 +1,5 @@ --- -title: kustomize를 사용하여 시크릿 관리 +title: kustomize를 사용하여 시크릿(Secret) 관리 content_type: task weight: 30 description: kustomization.yaml 파일을 사용하여 시크릿 오브젝트 생성. @@ -7,12 +7,9 @@ description: kustomization.yaml 파일을 사용하여 시크릿 오브젝트 -쿠버네티스 v1.14부터 `kubectl`은 -[Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. -Kustomize는 시크릿 및 컨피그맵을 생성하기 위한 리소스 생성기를 제공한다. -Kustomize 생성기는 디렉토리 내의 `kustomization.yaml` 파일에 지정되어야 한다. -시크릿 생성 후 `kubectl apply`를 통해 API -서버에 시크릿을 생성할 수 있다. +`kubectl`은 시크릿과 컨피그맵(ConfigMap)을 관리하기위해 [Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 +지원한다. Kustomize를 이용하여 *리소스 생성기*를 생성한다. 이는 `kubectl`을 +사용하여 API 서버에 적용할 수 있는 시크릿을 생성한다. ## {{% heading "prerequisites" %}} @@ -20,37 +17,46 @@ Kustomize 생성기는 디렉토리 내의 `kustomization.yaml` 파일에 지정 -## Kustomization 파일 생성 +## 시크릿 생성 -`kustomization.yaml` 파일에 다른 기존 파일을 참조하는 -`secretGenerator`를 정의하여 시크릿을 생성할 수 있다. -예를 들어 다음 kustomization 파일은 -`./username.txt` 및 `./password.txt` 파일을 참조한다. +`kustomization.yaml` 파일에 다른 기존 파일, `.env` 파일 및 +리터럴(literal) 값들을 참조하는 `secretGenerator`를 정의하여 시크릿을 생성할 수 있다. +예를 들어 다음 명령어는 사용자 이름 `admin`과 비밀번호 `1f2d1e2e67df` +를 위해 Kustomization 파일을 생성한다. -```yaml +### Kustomization 파일 생성 + +{{< tabs name="Secret data" >}} +{{< tab name="Literals" codelang="yaml" >}} secretGenerator: -- name: db-user-pass - files: - - username.txt - - password.txt -``` - -`kustomization.yaml` 파일에 리터럴을 명시하여 `secretGenerator`를 -정의할 수도 있다. -예를 들어 다음 `kustomization.yaml` 파일에는 -각각 `username`과 `password`에 대한 두 개의 리터럴이 포함되어 있다. - -```yaml -secretGenerator: -- name: db-user-pass +- name: database-creds literals: - username=admin - password=1f2d1e2e67df -``` +{{< /tab >}} +{{% tab name="Files" %}} +1. base64로 인코딩된 자격 증명의 값들을 파일에 저장한다. -`kustomization.yaml` 파일에 `.env` 파일을 명시하여 -`secretGenerator`를 정의할 수도 있다. -예를 들어 다음 `kustomization.yaml` 파일은 + ```shell + echo -n 'admin' > ./username.txt + echo -n '1f2d1e2e67df' > ./password.txt + ``` + `-n` 플래그는 파일의 끝에 개행 문자가 존재하지 않는 것을 + 보장한다. + +1. `kustomization.yaml` 파일 생성: + + ```yaml + secretGenerator: + - name: database-creds + files: + - username.txt + - password.txt + ``` +{{% /tab %}}} +{{% tab name=".env files" %}} +`kustomization.yaml` 파일에 `.env` 파일을 명시하여 시크릿 생성자를 +정의할 수도 있다. 예를 들어 다음 `kustomization.yaml` 파일은 `.env.secret` 파일에서 데이터를 가져온다. ```yaml @@ -59,81 +65,62 @@ secretGenerator: envs: - .env.secret ``` +{{% /tab %}} +{{< /tabs >}} -모든 경우에 대해, 값을 base64로 인코딩하지 않아도 된다. +모든 경우에 대해, 값을 base64로 인코딩하지 않아도 된다. YAML 파일의 이름은 +**무조건** `kustomization.yaml` 또는 `kustomization.yml` 이어야 한다. -## 시크릿 생성 +### kustomization 파일 적용 -다음 명령을 실행하여 시크릿을 생성한다. +시크릿을 생성하기 위해서 kustomization 파일을 포함하는 디렉토리에 적용한다. ```shell -kubectl apply -k . +kubectl apply -k ``` 출력은 다음과 유사하다. ``` -secret/db-user-pass-96mffmfh4k created +secret/database-creds-5hdh7hhgfk created ``` 시크릿이 생성되면 시크릿 데이터를 해싱하고 이름에 해시 값을 추가하여 시크릿 이름이 생성된다. 이렇게 함으로써 데이터가 수정될 때마다 시크릿이 새롭게 생성된다. -## 생성된 시크릿 확인 +시크릿이 생성되었는지 확인하고 시크릿 데이터를 디코딩하려면, 다음을 참조한다. +[kubectl을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#verify-the-secret). -시크릿이 생성된 것을 확인할 수 있다. +## 시크릿 편집 {#edit-secret} -```shell -kubectl get secrets -``` +1. `kustomization.yaml` 파일에서 `password`와 같은 데이터를 수정한다. +1. kustomization 파일을 포함하는 디렉토리에 적용한다: -출력은 다음과 유사하다. + ```shell + kubectl apply -k + ``` -``` -NAME TYPE DATA AGE -db-user-pass-96mffmfh4k Opaque 2 51s -``` + 출력은 다음과 유사하다. -다음 명령을 실행하여 시크릿에 대한 상세 사항을 볼 수 있다. + ``` + secret/db-user-pass-6f24b56cc8 created + ``` -```shell -kubectl describe secrets/db-user-pass-96mffmfh4k -``` - -출력은 다음과 유사하다. - -``` -Name: db-user-pass-96mffmfh4k -Namespace: default -Labels: -Annotations: - -Type: Opaque - -Data -==== -password.txt: 12 bytes -username.txt: 5 bytes -``` - -`kubectl get` 및 `kubectl describe` 명령은 기본적으로 `시크릿`의 내용을 표시하지 않는다. -이는 `시크릿`이 실수로 구경꾼에게 노출되는 것을 방지하기 위한 것으로, -또는 터미널 로그에 저장되지 않는다. -인코딩된 데이터의 실제 내용을 확인하려면 다음을 참조한다. -[시크릿 디코딩](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret). +편집된 시크릿은 존재하는 `Secret` 오브젝트를 업데이트하는 것이 아니라 +새로운 `Secret` 오브젝트로 생성된다. 따라서 파드에서 시크릿에 대한 참조를 +업데이트해야 한다. ## 삭제 -생성한 시크릿을 삭제하려면 다음 명령을 실행한다. +시크릿을 삭제하려면 `kubectl`을 사용한다. ```shell -kubectl delete secret db-user-pass-96mffmfh4k +kubectl delete secret db-user-pass ``` - ## {{% heading "whatsnext" %}} - [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기 -- [`kubectl` 커맨드을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) 방법 알아보기 -- [환경 설정 파일을 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 알아보기 +- [kubectl을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) 방법 알아보기 +- [환경 설정 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) 방법 알아보기 \ No newline at end of file From f15cef5932512bf81764a27dc214f2943c495aa7 Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Fri, 5 May 2023 14:48:04 +0900 Subject: [PATCH 48/69] [ko] translate docs/tasks/job/job-with-pod-to-pod-communication --- .../job/job-with-pod-to-pod-communication.md | 126 ++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 content/ko/docs/tasks/job/job-with-pod-to-pod-communication.md diff --git a/content/ko/docs/tasks/job/job-with-pod-to-pod-communication.md b/content/ko/docs/tasks/job/job-with-pod-to-pod-communication.md new file mode 100644 index 0000000000..316839b239 --- /dev/null +++ b/content/ko/docs/tasks/job/job-with-pod-to-pod-communication.md @@ -0,0 +1,126 @@ +--- +title: 파드 간 통신이 활성화된 잡 +content_type: task +min-kubernetes-server-version: v1.21 +weight: 30 +--- + + + +이 예제에서는, 파드의 IP 주소 대신 호스트네임으로 상호 통신할 수 있도록 파드를 생성하는 잡을 +[색인된 완료 모드(Indexed completion mode)](/blog/2021/04/19/introducing-indexed-jobs/)로 구성하여 실행한다. + +잡 내부의 파드들이 서로 통신해야 하는 경우가 있다. 각 파드에서 실행되는 사용자 워크로드에서 쿠버네티스 API 서버에 +질의하여 다른 파드의 IP를 알아낼 수도 있지만, 쿠버네티스에 내장된 DNS 변환(resolution)을 활용하는 것이 훨씬 간편하다. + +색인된 완료 모드의 잡은 자동으로 파드의 호스트네임을 `${jobName}-${completionIndex}` 형식으로 설정한다. +이 형식을 활용하면 파드 호스트네임을 결정론적(deterministically)으로 빌드하고 파드 간 통신을 활성화할 수 있다. +쿠버네티스 컨트롤 플레인에 대해 클라이언트 연결을 생성하고 API 요청으로 파드 호스트네임 및 IP를 알아낼 필요 없이 말이다. + +이러한 설정은 파드 네트워킹이 필요하지만 +쿠버네티스 API 서버와의 네트워크 연결에 의존하지 않고 싶은 경우에 유용하다. + +## {{% heading "prerequisites" %}} + +기본적으로 [잡](/ko/docs/concepts/workloads/controllers/job/) 사용 방법에 익숙하다는 것을 가정한다. + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{}} +MiniKube 혹은 유사한 도구를 사용하고 있다면 DNS 셋업을 위해 +[추가적인 작업](https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/)이 +필요할 수 있다. +{{}} + + + +## 파드 간 통신이 활성화된 잡 시작하기 + +잡의 파드 호스트네임을 활용한 파드 간 통신을 활성화하기 위해서는 다음 작업을 진행해야 한다. + +1. 잡으로 생성되는 파드들에 대한 레이블 셀렉터를 지닌 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만든다. +헤드리스 서비스는 반드시 잡과 동일한 네임스페이스에 생성해야 한다. +쿠버네티스에 의해 `job-name` 레이블이 자동으로 생성되므로 `job-name: ` 셀렉터를 활용하면 간단하다. +해당 설정은 잡에서 실행 중인 파드들의 호스트네임에 대한 레코드를 생성하도록 DNS 시스템을 트리거할 것이다. + +2. 잡 템플릿 스펙에 아래 값을 추가함으로써 헤드리스 서비스를 잡의 파드들의 서브도메인 서비스로 설정한다. + + ```yaml + subdomain: + ``` + +### 예제 +아래는 파드 호스트네임을 통해 파드 간 통신이 활성화된 잡의 예시이다. +해당 잡은 모든 파드들이 호스트네임으로 상호 핑(ping)을 성공한 경우에만 완료된다. +{{}} +네임스페이스 외부에서 잡의 파드들에 접근해야 한다면, 아래 예시의 +각 파드에서 실행되는 배쉬(Bash) 스크립트에서 파드 호스트네임에 네임스페이스를 접두사로 추가하면 된다. +{{}} + +```yaml + +apiVersion: v1 +kind: Service +metadata: + name: headless-svc +spec: + clusterIP: None # 헤드리스 서비스를 생성하기 위해서는 clusterIP가 반드시 None이어야 한다. + selector: + job-name: example-job # 잡의 name과 일치해야 한다. +--- +apiVersion: batch/v1 +kind: Job +metadata: + name: example-job +spec: + completions: 3 + parallelism: 3 + completionMode: Indexed + template: + spec: + subdomain: headless-svc # 서비스의 name과 일치해야 한다. + restartPolicy: Never + containers: + - name: example-workload + image: bash:latest + command: + - bash + - -c + - | + for i in 0 1 2 + do + gotStatus="-1" + wantStatus="0" + while [ $gotStatus -ne $wantStatus ] + do + ping -c 1 example-job-${i}.headless-svc > /dev/null 2>&1 + gotStatus=$? + if [ $gotStatus -ne $wantStatus ]; then + echo "Failed to ping pod example-job-${i}.headless-svc, retrying in 1 second..." + sleep 1 + fi + done + echo "Successfully pinged pod: example-job-${i}.headless-svc" + done +``` + +위의 예제를 적용한 이후, `.`를 사용하여 네트워크 상으로 서로 통신해보자. +아래와 유사한 내용이 출력될 것이다. + +```shell +kubectl logs example-job-0-qws42 +``` + +``` +Failed to ping pod example-job-0.headless-svc, retrying in 1 second... +Successfully pinged pod: example-job-0.headless-svc +Successfully pinged pod: example-job-1.headless-svc +Successfully pinged pod: example-job-2.headless-svc +``` + +{{}} +해당 예제에서 사용된 `.` 이름 형식은 +DNS 정책을 `None` 혹은 `Default`로 설정할 경우 제대로 동작하지 않을 것임에 유의해야 한다. +파드 DNS 정책에 대해 더 배우고 싶다면 +[여기](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-dns-정책)를 참고하자. +{{}} From e76a388027ddc5e800082d7b4048995d6d686eba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Tue, 16 May 2023 01:07:34 +0900 Subject: [PATCH 49/69] [ko] Update outdated files in dev-1.26-ko.1 (M158) --- .../configure-persistent-volume-storage.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 1d6a88c6cf..51f591c4eb 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -86,9 +86,9 @@ Hello from Kubernetes storage 운영 클러스터에서, 사용자가 hostPath를 사용하지는 않는다. 대신, 클러스터 관리자는 Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는 -[스토리지클래스(StorageClasses)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)를 +[스토리지클래스(StorageClasses)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage-k8s-io)를 사용하여 -[동적 프로비저닝](/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)을 설정할 수도 있다. +[동적 프로비저닝](/docs/concepts/storage/dynamic-provisioning/)을 설정할 수도 있다. hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다. From 0c6b2e05b7f354d93e201835b9ac9b6dd68ca03e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Tue, 16 May 2023 01:19:13 +0900 Subject: [PATCH 50/69] [ko] Update outdated files in dev-1.26-ko.1 (M159) --- .../configure-volume-storage.md | 117 ++++++++---------- 1 file changed, 53 insertions(+), 64 deletions(-) diff --git a/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md index 73c7493909..bf636fab4c 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -14,15 +14,10 @@ weight: 50 사용할 수 있다. 이것은 레디스(Redis)와 같은 키-값 저장소나 데이터베이스와 같은 스테이트풀 애플리케이션에 매우 중요하다. - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - ## 파드에 볼륨 구성 @@ -37,71 +32,71 @@ weight: 50 1. 파드 생성 - ```shell - kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml + ``` 1. 파드의 컨테이너가 Running 중인지 확인하고, 파드의 변경사항을 지켜본다. - ```shell - kubectl get pod redis --watch - ``` + ```shell + kubectl get pod redis --watch + ``` - 출력은 이와 유사하다. + 출력은 이와 유사하다. - ```shell - NAME READY STATUS RESTARTS AGE - redis 1/1 Running 0 13s - ``` + ```shell + NAME READY STATUS RESTARTS AGE + redis 1/1 Running 0 13s + ``` 1. 다른 터미널에서 실행 중인 컨테이너의 셸을 획득한다. - ```shell - kubectl exec -it redis -- /bin/bash - ``` + ```shell + kubectl exec -it redis -- /bin/bash + ``` 1. 셸에서 `/data/redis` 로 이동하고, 파일을 생성한다. - ```shell - root@redis:/data# cd /data/redis/ - root@redis:/data/redis# echo Hello > test-file - ``` + ```shell + root@redis:/data# cd /data/redis/ + root@redis:/data/redis# echo Hello > test-file + ``` 1. 셸에서 실행 중인 프로세스 목록을 확인한다. - ```shell - root@redis:/data/redis# apt-get update - root@redis:/data/redis# apt-get install procps - root@redis:/data/redis# ps aux - ``` + ```shell + root@redis:/data/redis# apt-get update + root@redis:/data/redis# apt-get install procps + root@redis:/data/redis# ps aux + ``` - 출력은 이와 유사하다. + 출력은 이와 유사하다. - ```shell - USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND - redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 - root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash - root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux - ``` + ```shell + USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND + redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 + root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash + root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux + ``` 1. 셸에서 Redis 프로세스를 강제종료(kill)한다. - ```shell - root@redis:/data/redis# kill - ``` + ```shell + root@redis:/data/redis# kill + ``` - 여기서 ``는 Redis 프로세스 ID(PID) 이다. + 여기서 ``는 Redis 프로세스 ID(PID) 이다. 1. 원래 터미널에서, Redis 파드의 변경을 지켜본다. 결국, -다음과 유사한 것을 보게 될 것이다. + 다음과 유사한 것을 보게 될 것이다. - ```shell - NAME READY STATUS RESTARTS AGE - redis 1/1 Running 0 13s - redis 0/1 Completed 0 6m - redis 1/1 Running 1 6m - ``` + ```shell + NAME READY STATUS RESTARTS AGE + redis 1/1 Running 0 13s + redis 0/1 Completed 0 6m + redis 1/1 Running 1 6m + ``` 이때, 컨테이너는 종료되고 재시작된다. 이는 Redis 파드의 @@ -110,28 +105,26 @@ Redis 파드의 1. 재시작된 컨테이너의 셸을 획득한다. - ```shell - kubectl exec -it redis -- /bin/bash - ``` + ```shell + kubectl exec -it redis -- /bin/bash + ``` 1. 셸에서 `/data/redis` 로 이동하고, `test-file` 이 여전히 존재하는지 확인한다. - ```shell - root@redis:/data/redis# cd /data/redis/ - root@redis:/data/redis# ls - test-file - ``` + + ```shell + root@redis:/data/redis# cd /data/redis/ + root@redis:/data/redis# ls + test-file + ``` 1. 이 연습을 위해 생성한 파드를 삭제한다. - ```shell - kubectl delete pod redis - ``` - - + ```shell + kubectl delete pod redis + ``` ## {{% heading "whatsnext" %}} - * [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 참고한다. * [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 참고한다. @@ -141,7 +134,3 @@ Redis 파드의 네트워크 연결 스토리지(NAS) 솔루션을 지원하며, 노드의 디바이스 마운트, 언마운트와 같은 세부사항을 처리한다. 자세한 내용은 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고한다. - - - - From 4d5e9205872f9f7ef40ab1bd026b7f030d256ada Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Tue, 16 May 2023 01:27:40 +0900 Subject: [PATCH 51/69] [ko] Update outdated files in dev-1.26-ko.1 (M160) --- .../configure-pod-container/pull-image-private-registry.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index 87efe777a9..0a11eed578 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -61,6 +61,7 @@ cat ~/.docker/config.json {{< note >}} 도커 자격 증명 저장소를 사용하는 경우, `auth` 항목이 아닌, 저장소의 이름을 값으로 사용하는 `credsStore` 항목을 확인할 수 있다. +이 경우, 시크릿을 직접 생성할 수 있다. [커맨드 라인에서 자격 증명을 통하여 시크릿 생성하기](#커맨드-라인에서-자격-증명을-통하여-시크릿-생성하기)를 보자. {{< /note >}} ## 기존의 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials} @@ -190,7 +191,7 @@ janedoe:xxxxxxxxxxx 위 파일을 컴퓨터에 다운로드한다. ```shell -curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +curl -L -o my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml ``` `my-private-reg-pod.yaml` 파일 안에서, `` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다. From 1bcdcd5354edc91f38ddb402c5e2f03a47b4130f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Tue, 16 May 2023 01:32:15 +0900 Subject: [PATCH 52/69] [ko] Update outdated files in dev-1.26-ko.1 (M161) --- content/ko/docs/tasks/configure-pod-container/static-pod.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index a34628eed3..309a834a9e 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -38,6 +38,10 @@ API 서버에서 제어될 수는 없다. {{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다. {{< /note >}} +{{< note >}} +스태틱 파드는 [임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 지원하지 않는다. +{{< /note >}} + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} From 48cd844da5220e055dfd7c1acc09c2c38f900f8c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=86=90=EB=B3=91=EC=9E=AC?= Date: Tue, 16 May 2023 01:38:04 +0900 Subject: [PATCH 53/69] =?UTF-8?q?=ED=95=9C=EA=B8=80=20=EB=AC=B8=EC=84=9C?= =?UTF-8?q?=EB=A1=9C=20url=EB=B3=80=EA=B2=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../configure-persistent-volume-storage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 51f591c4eb..40f4dd7c6d 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -88,7 +88,7 @@ Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는 [스토리지클래스(StorageClasses)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage-k8s-io)를 사용하여 -[동적 프로비저닝](/docs/concepts/storage/dynamic-provisioning/)을 설정할 수도 있다. +[동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 설정할 수도 있다. hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다. From c3d33d09cf97d443563ea0033e08e053b01360e9 Mon Sep 17 00:00:00 2001 From: YujinChoi Date: Tue, 16 May 2023 15:22:23 +0900 Subject: [PATCH 54/69] [ko] Update outdated files in `dev-1.26-ko.1` (M61) --- .../services-networking/endpoint-slices.md | 99 ++++++++++++------- 1 file changed, 62 insertions(+), 37 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 0b2e98138e..1548053a6a 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -3,7 +3,11 @@ # - freehan title: 엔드포인트슬라이스 content_type: concept -weight: 45 +weight: 60 +description: >- + 엔드포인트슬라이스 API는 서비스가 대규모 백엔드를 처리할 수 있도록 확장할 수 있게 해주고, + 클러스터가 정상적인 백엔드의 리스트를 효율적으로 업데이트 할 수 있도록 + 쿠버네티스가 사용하는 메커니즘이다. --- @@ -11,32 +15,13 @@ weight: 45 {{< feature-state for_k8s_version="v1.21" state="stable" >}} -_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를 -추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한 +쿠버네티스의 _엔드포인트슬라이스_ API 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를 +추적하는 방법을 제공한다. 엔드포인트슬라이스는 [엔드포인트](/ko/docs/concepts/services-networking/service/#endpoints)보다 더 유동적이고, 확장 가능한 대안을 제안한다. - - -## 사용동기 - -엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는 -간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와 -{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로 -더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게 -되었다. -특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에 -어려움이 있었다. - -이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트 -리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스 -구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고 -엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다. -엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과 -같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다. - -## 엔드포인트슬라이스 리소스 {#endpointslice-resource} +## 엔드포인트슬라이스 API {#endpointslice-resource} 쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한 참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터" @@ -48,8 +33,8 @@ term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로 엔드포인트슬라이스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스 -리소스 샘플이 있다. +예를 들어, 여기에 `example` 쿠버네티스 서비스가 소유하는 엔드포인트슬라이스 +객체 샘플이 있다. ```yaml apiVersion: discovery.k8s.io/v1 @@ -81,8 +66,7 @@ endpoints: 엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에 -신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는 -서비스에 대해 성능 향상을 제공해야 한다. +신뢰할 수 있는 소스로 역할을 할 수 있다. ### 주소 유형 @@ -92,12 +76,16 @@ endpoints: * IPv6 * FQDN (전체 주소 도메인 이름) -### 조건 +각 엔드포인트슬라이스 객체는 특정한 IP 주소 유형을 나타낸다. +IPv4와 IPv6를 사용할 수 있는 서비스가 있을 경우, +최소 두개의 엔드포인트슬라이스 객체가 존재한다(IPv4를 위해 하나, IPv6를 위해 하나). + +### 컨디션 엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다. -조건은 `준비`, `제공` 및 `종료` 세 가지가 있다. +조건은 `ready`, `serving` 및 `Terminating` 세 가지가 있다. -#### 준비 +#### Ready `ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는 이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의 @@ -106,7 +94,7 @@ endpoints: 이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다. 이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다. -#### 제공(Serving) +#### Serving {{< feature-state for_k8s_version="v1.22" state="beta" >}} @@ -125,14 +113,14 @@ endpoints: {{< /note >}} -#### 종료(Terminating) +#### Terminating {{< feature-state for_k8s_version="v1.22" state="beta" >}} `종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다. 파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다. -### 토폴로지 정보 {#토폴로지} +### 토폴로지 정보 {#topology} 엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다. 토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및 @@ -242,11 +230,48 @@ v1 API의 `zone` 필드로 접근할 수 있다. 엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의 엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에 대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에 -도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은 -엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트 -중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의 +도착할 수 있기 때문에 자연스럽게 발생한다. + +{{< note >}} +엔드포인트슬라이스 API의 클라이언트는 반드시 서비스에 연관된 모든 존재하는 엔드포인트슬라이스에 대해 +반복하고, 고유한 각 네트워크 엔드포인트들의 완전한 리스트를 구성해야 한다. 엔드포인트는 다른 +엔드포인트슬라이스에서 중복될 수 있음에 유의한다. + +엔드포인트 집계와 중복 제거 방법에 대한 레퍼런스 구현은 `kube-proxy` 의 `EndpointSliceCache` 구현에서 찾을 수 있다. +{{< /note >}} + +## 엔드포인트와 비교 {#motivation} + +기존 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는 +간단하고 직접적인 방법을 제공했다. 쿠버네티스 클러스터와 +{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로 +더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게 +되었다. +특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에 +어려움이 있었다. + +서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트 +객체에 저장되기 때문에 이러한 엔드포인트 객체들이 상당히 커지는 경우도 있었다. 안정적인 +서비스(오랜 기간 동안 같은 엔드포인트 세트)의 경우 영향은 +비교적 덜 눈에 띄지만, 여전히 쿠버네티스의 일부 사용 사례들은 잘 처리되지 않았다. + +서비스가 많은 백엔드 엔드포인트를 가지고 +워크로드가 자주 증가하거나, 새로운 변경사항이 자주 롤 아웃 될 경우, +해당 서비스의 단일 엔드포인트 객체에 대한 각 업데이트는 +쿠버네티스 클러스터 컴포넌트 사이(컨트롤 플레인 내, 그리고 노드와 API 서버 사이)에 +상당한 네트워크 트래픽이 발생할 것임을 의미했다. +이러한 추가 트래픽은 또한 CPU 사용 관점에서도 굉장한 비용을 발생시켰다. + +엔드포인트슬라이스 사용 시, 단일 파드를 추가하거나 삭제하는 작업은 (다수의 파드를 추가/삭제하는 작업과 비교했을 때) +해당 변경을 감시하고 있는 클라이언트에 동일한 _수_의 업데이트를 트리거한다. +하지만, 파드 대규모 추가/삭제의 경우 업데이트 메시지의 크기는 훨씬 작다. + +엔드포인트슬라이스는 듀얼 스택 네트워킹과 토폴로지 인식 라우팅과 같은 +새로운 기능에 대한 혁신을 가능하게 했다. ## {{% heading "whatsnext" %}} -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 +* [서비스와 애플리케이션 연결하기](/docs/concepts/services-networking/connect-applications-service/) 튜토리얼을 따라하기 +* [엔드포인트슬라이스 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 를 읽어보기 +* [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기 \ No newline at end of file From c1cd13e00861d85a0753227e854af275302c1522 Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Sun, 21 May 2023 14:38:55 +0900 Subject: [PATCH 55/69] [ko] Update outdated files in dev-1.26.-ko.1 [M28-33] --- .../compute-storage-net/device-plugins.md | 87 +++++++++------ .../compute-storage-net/network-plugins.md | 35 ++++-- .../concepts/extend-kubernetes/operator.md | 6 +- content/ko/docs/concepts/overview/_index.md | 105 ++++++++++++------ .../ko/docs/concepts/overview/components.md | 6 +- .../docs/concepts/overview/kubernetes-api.md | 25 +++-- 6 files changed, 171 insertions(+), 93 deletions(-) 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 bd48985467..d240d73611 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 @@ -1,12 +1,14 @@ --- title: 장치 플러그인 -description: 장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치 또는 리소스를 클러스터에서 지원하도록 설정할 수 있다. +description: > + 장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치 + 또는 리소스를 클러스터에서 지원하도록 설정할 수 있다. content_type: concept weight: 20 --- -{{< feature-state for_k8s_version="v1.10" state="beta" >}} +{{< feature-state for_k8s_version="v1.26" state="stable" >}} 쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는 [장치 플러그인 프레임워크](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)를 @@ -33,12 +35,12 @@ service Registration { 장치 플러그인은 이 gRPC 서비스를 통해 kubelet에 자체 등록할 수 있다. 등록하는 동안, 장치 플러그인은 다음을 보내야 한다. - * 유닉스 소켓의 이름. - * 빌드된 장치 플러그인 API 버전. - * 알리려는 `ResourceName`. 여기서 `ResourceName` 은 - [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 - `vendor-domain/resourcetype` 의 형식으로 따라야 한다. - (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.) +* 유닉스 소켓의 이름. +* 빌드된 장치 플러그인 API 버전. +* 알리려는 `ResourceName`. 여기서 `ResourceName` 은 + [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 + `vendor-domain/resourcetype` 의 형식으로 따라야 한다. + (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.) 성공적으로 등록하고 나면, 장치 플러그인은 kubelet이 관리하는 장치 목록을 전송한 다음, kubelet은 kubelet 노드 상태 업데이트의 일부로 @@ -102,7 +104,7 @@ spec: rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {} // 컨테이너를 생성하는 동안 Allocate가 호출되어 장치 - // 플러그인이 장치별 작업을 실행하고 Kubelet에 장치를 + // 플러그인이 장치별 작업을 실행하고 kubelet에 장치를 // 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다. rpc Allocate(AllocateRequest) returns (AllocateResponse) {} @@ -133,17 +135,17 @@ spec: 유닉스 소켓을 통해 kubelet에 직접 등록한다. * 성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를 -모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다. -또한 gRPC 요청 `Allocate` 를 담당한다. `Allocate` 하는 동안, 장치 플러그인은 -GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다. -작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된 -`AllocateResponse` 를 반환한다. kubelet은 이 정보를 -컨테이너 런타임에 전달한다. + 모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다. + 또한 gRPC 요청 `Allocate` 를 담당한다. `Allocate` 하는 동안, 장치 플러그인은 + GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다. + 작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된 + `AllocateResponse` 를 반환한다. kubelet은 이 정보를 + 컨테이너 런타임에 전달한다. ### kubelet 재시작 처리 장치 플러그인은 일반적으로 kubelet의 재시작을 감지하고 새로운 -kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현재의 구현에서, 새 kubelet 인스턴스는 시작될 때 +kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 새 kubelet 인스턴스는 시작될 때 `/var/lib/kubelet/device-plugins` 아래에 있는 모든 기존의 유닉스 소켓을 삭제한다. 장치 플러그인은 유닉스 소켓의 삭제를 모니터링하고 이러한 이벤트가 발생하면 다시 자신을 등록할 수 있다. @@ -164,16 +166,26 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현 ## API 호환성 -쿠버네티스 장치 플러그인 지원은 베타 버전이다. 호환되지 않는 방식으로 안정화 전에 API가 -변경될 수 있다. 프로젝트로서, 쿠버네티스는 장치 플러그인 개발자에게 다음 사항을 권장한다. +과거에는 장치 플러그인의 API 버전을 반드시 kubelet의 버전과 정확하게 일치시켜야 했다. +해당 기능이 v1.12의 베타 버전으로 올라오면서 이는 필수 요구사항이 아니게 되었다. +해당 기능이 베타 버전이 된 이후로 API는 버전화되었고 그동안 변하지 않았다. +그러므로 kubelet 업그레이드를 원활하게 진행할 수 있을 것이지만, +안정화되기 전까지는 향후 API가 변할 수도 있으므로 업그레이드를 했을 때 절대로 문제가 없을 것이라고는 보장할 수는 없다. -* 향후 릴리스에서 변경 사항을 확인하자. -* 이전/이후 버전과의 호환성을 위해 여러 버전의 장치 플러그인 API를 지원한다. +{{< caution >}} +쿠버네티스의 장치 관리자 컴포넌트는 안정화된(GA) 기능이지만 _장치 플러그인 API_는 안정화되지 않았다. +장치 플러그인 API와 버전 호환성에 대한 정보는 [장치 플러그인 API 버전](/docs/reference/node/device-plugin-api-versions/)를 참고하라. +{{< caution >}} -최신 장치 플러그인 API 버전의 쿠버네티스 릴리스로 업그레이드해야 하는 노드에서 DevicePlugins 기능을 활성화하고 -장치 플러그인을 실행하는 경우, 이 노드를 업그레이드하기 전에 -두 버전을 모두 지원하도록 장치 플러그인을 업그레이드한다. 이 방법을 사용하면 -업그레이드 중에 장치 할당이 지속적으로 작동한다. +프로젝트로서, 쿠버네티스는 장치 플러그인 개발자에게 다음 사항을 권장한다. + +* 향후 릴리스에서 장치 플러그인 API의 변경 사항을 확인하자. +* 이전/이후 버전과의 호환성을 위해 여러 버전의 장치 플러그인 API를 지원하자. + +최신 장치 플러그인 API 버전의 쿠버네티스 릴리스로 업그레이드해야 하는 노드에서 +장치 플러그인을 실행하기 위해서는, 해당 노드를 업그레이드하기 전에 +두 버전을 모두 지원하도록 장치 플러그인을 업그레이드해야 한다. 이러한 방법은 +업그레이드 중에 장치 할당이 지속적으로 동작할 것을 보장한다. ## 장치 플러그인 리소스 모니터링 @@ -273,8 +285,9 @@ List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources` 노출된 기본 리소스가 변경되지 않는 한 동일하게 유지된다. 이러한 변경은 드물지만, 발생하게 된다면 (예를 들면: hotplug/hotunplug, 장치 상태 변경) 클라이언트가 `GetAlloctableResources` 엔드포인트를 호출할 것으로 가정한다. + 그러나 CPU 및/또는 메모리가 갱신된 경우 `GetAllocateableResources` 엔드포인트를 호출하는 것만으로는 -충분하지 않으며, Kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다. +충분하지 않으며, kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다. {{< /note >}} @@ -288,12 +301,14 @@ message AllocatableResourcesResponse { ``` 쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다. -이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -끄면 된다. +이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` +[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 끄면 된다. 쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다. -`--feature-gates=KubeletPodResourcesGetAllocatable=true` +``` +--feature-gates=KubeletPodResourcesGetAllocatable=true +``` `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다. NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은 @@ -315,7 +330,8 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -토폴로지 관리자는 Kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. 이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다. +토폴로지 관리자는 kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. +이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다. ```gRPC @@ -327,9 +343,15 @@ message NUMANode { int64 ID = 1; } ``` -토폴로지 관리자를 활용하려는 장치 플러그인은 장치 ID 및 장치의 정상 상태와 함께 장치 등록의 일부로 채워진 TopologyInfo 구조체를 다시 보낼 수 있다. 그런 다음 장치 관리자는 이 정보를 사용하여 토폴로지 관리자와 상의하고 리소스 할당 결정을 내린다. -`TopologyInfo` 는 `nil`(기본값) 또는 NUMA 노드 목록인 `nodes` 필드를 지원한다. 이를 통해 NUMA 노드에 걸쳐있을 수 있는 장치 플러그인을 게시할 수 있다. +토폴로지 관리자를 활용하려는 장치 플러그인은 장치 ID 및 장치의 정상 상태와 함께 장치 등록의 일부로 채워진 TopologyInfo 구조체를 다시 보낼 수 있다. +그런 다음 장치 관리자는 이 정보를 사용하여 토폴로지 관리자와 상의하고 리소스 할당 결정을 내린다. + +`TopologyInfo` 는 `nodes` 필드에 `nil`(기본값) 또는 NUMA 노드 목록을 설정하는 것을 지원한다. +이를 통해 복수의 NUMA 노드에 연관된 장치에 대해 장치 플러그인을 설정할 수 있다. + +특정 장치에 대해 `TopologyInfo`를 `nil`로 설정하거나 비어있는 NUMA 노드 목록을 제공하는 것은 +장치 플러그인이 해당 장치에 대한 NUMA 선호도(affinity)를 지니지 못함을 시사한다. 장치 플러그인으로 장치에 대해 채워진 `TopologyInfo` 구조체의 예는 다음과 같다. @@ -351,8 +373,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * [SocketCAN 장치 플러그인](https://github.com/collabora/k8s-socketcan) * [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin) * [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin) -* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) - +* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-device-plugin) ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 525a2b11d8..93ad7a0cf0 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -11,8 +11,10 @@ weight: 10 -쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다. -클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스). +쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 +[컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다. +사용 중인 클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. +더 넓은 쿠버네티스 생태계에 다양한 플러그인이 (오픈소스와 클로즈드 소스로) 존재한다. CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. @@ -26,7 +28,8 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/ ## 설치 -네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다. +네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. +특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다. {{< note >}} 쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다. @@ -37,28 +40,35 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/ {{< /note >}} 컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자. -- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni) -- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) -CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 [네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조한다. + - [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni) + - [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) + +CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 +[네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조하자. ## 네트워크 플러그인 요구 사항 쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다. iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. -예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. +예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 +`1`로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다. -kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다. +kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, +`net/bridge/bridge-nf-call-iptables=1`을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다. ### 루프백 CNI -쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다. -루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)) +쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 +사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다. +루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 +재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)) ### hostPort 지원 -CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 [포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) +CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 +[포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) 플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다. `hostPort` 지원을 사용하려면, `cni-conf-dir` 에 `portMappings capability` 를 지정해야 한다. @@ -97,7 +107,8 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 **실험적인 기능입니다** -CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 지원한다. CNI 플러그인 팀에서 제공하는 공식 [대역폭(bandwidth)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) +CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 지원한다. CNI 플러그인 팀에서 제공하는 +공식 [대역폭(bandwidth)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다. 트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index f93d332c4a..ac1b7e10d4 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -31,9 +31,11 @@ _오퍼레이터 패턴_ 은 서비스 또는 서비스 셋을 관리하는 운 및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을 자동화할 수 있다. -쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다. +쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} +개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 +하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다. 오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의 -컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다. +컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트다. ## 오퍼레이터 예시 {#example} diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md index eed332a41f..82c2048bf1 100644 --- a/content/ko/docs/concepts/overview/_index.md +++ b/content/ko/docs/concepts/overview/_index.md @@ -18,9 +18,16 @@ no_list: true -쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. -쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. +쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. +쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. +쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. + +쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 +그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. +쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 +[15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 +커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. ## 여정 돌아보기 @@ -29,69 +36,101 @@ no_list: true ![배포 혁명](/images/docs/Container_Evolution.svg) **전통적인 배포 시대:** -초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다. +초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, +리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, +결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다. +그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으며, 조직이 많은 물리 서버를 유지하는 데에 높은 비용이 들었다. -**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다. +**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. +가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다. -가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다. +가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 +하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) +가상 머신으로 구성된 클러스터로 만들 수 있다. 각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다. -**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. +**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. +그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. +기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. -컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. +컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 유명해졌다. -* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임. -* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다. -* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. +* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적이다. +* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 + 효율적으로 롤백할 수 있다. +* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 + 인프라스트럭처에서 분리된다. * 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다. * 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다. -* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다. -* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다. -* 리소스 격리: 애플리케이션 성능을 예측할 수 있다. -* 리소스 사용량: 고효율 고집적. +* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 + 실행하는 수준으로 추상화 수준이 높아진다. +* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 + 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다. + * 리소스 격리: 애플리케이션 성능을 예측할 수 있다. + * 리소스 사용량: 고효율 고집적. ## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do} -컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? +컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 +가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. +이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? -그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다. +그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. +애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리할 수 있다. 쿠버네티스는 다음을 제공한다. * **서비스 디스커버리와 로드 밸런싱** -쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. + 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, + 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. * **스토리지 오케스트레이션** -쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다. +쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다 * **자동화된 롤아웃과 롤백** -쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다. + 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. + 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다. * **자동화된 빈 패킹(bin packing)** -컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다. + 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 + 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다. * **자동화된 복구(self-healing)** -쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. + 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, + 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. * **시크릿과 구성 관리** -쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다. + 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. + 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다. ## 쿠버네티스가 아닌 것 -쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. +쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. +쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, +로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, +쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. +쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. 쿠버네티스는: -* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. -* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다. -* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. +* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, + 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. + 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. +* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 + 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다. +* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), + 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. + 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 + [Open Service Broker](https://openservicebrokerapi.org/)와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. * 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. -* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. - - +* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. + 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. + 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 + 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 + 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. ## {{% heading "whatsnext" %}} -* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 -* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/) 살펴보기 -* [클러스터 아키텍처](/ko/docs/concepts/architecture/) 살펴보기 -* [시작하기](/ko/docs/setup/) 준비가 되었는가? +* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 +* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/) 살펴보기 +* [클러스터 아키텍처](/ko/docs/concepts/architecture/) 살펴보기 +* [시작](/ko/docs/setup/)할 준비가 되었는가? diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index e02d749121..4e2319ac9b 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -6,7 +6,7 @@ content_type: concept description: > 쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다. -weight: 20 +weight: 30 card: name: concepts weight: 20 @@ -53,8 +53,8 @@ card: * 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다. * 잡 컨트롤러: 일회성 작업을 나타내는 잡 오브젝트를 감시한 다음, 해당 작업을 완료할 때까지 동작하는 파드를 생성한다. - * 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.) - * 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다. + * 엔드포인트슬라이스 컨트롤러: (서비스와 파드 사이의 연결고리를 제공하기 위해) 엔드포인트슬라이스(EndpointSlice) 오브젝트를 채운다 + * 서비스어카운트 컨트롤러: 새로운 네임스페이스에 대한 기본 서비스어카운트(ServiceAccount)를 생성한다. ### cloud-controller-manager diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index a45a77b384..14626f7121 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -3,7 +3,7 @@ # - chenopis title: 쿠버네티스 API content_type: concept -weight: 30 +weight: 40 description: > 쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다. 쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다. @@ -180,9 +180,10 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스 동일한 기본 데이터를 제공할 수 있다. 예를 들어, 동일한 리소스에 대해 `v1` 과 `v1beta1` 이라는 두 가지 API 버전이 -있다고 가정한다. 원래 API의 `v1beta1` 버전을 사용하여 오브젝트를 -만든 경우, 나중에 `v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를 -읽거나, 업데이트하거나, 삭제할 수 있다. +있다고 가정하자. API의 `v1beta1` 버전을 사용하여 오브젝트를 만든 경우, +`v1beta1` 버전이 사용 중단(deprecated)되고 제거될 때까지는 +`v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를 읽거나, 업데이트하거나, 삭제할 수 있다. +그 이후부터는 `v1` API를 사용하여 계속 오브젝트에 접근하고 수정할 수 있다. ## API 변경 사항 @@ -197,14 +198,18 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스 쿠버네티스는 일반적으로 API 버전 `v1` 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에 대한 호환성 유지를 강력하게 이행한다. 또한, -쿠버네티스는 가능한 경우 _베타_ API 버전에서도 호환성을 유지한다. -베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와 -계속 상호 작용할 수 있다. +쿠버네티스는 공식 쿠버네티스 API의 _베타_ API 버전으로 만들어진 데이터와도 호환성을 유지하며, +해당 기능이 안정화되었을 때 해당 데이터가 안정 버전(GA)의 API 버전들에 의해 변환되고 접근될 수 있도록 보장한다. + +만약 베타 API 버전을 사용했다면, 해당 API가 승급했을 때 후속 베타 버전 혹은 안정된 버전의 API로 전환해야 한다. +해당 작업은 오브젝트 접근을 위해 두 API 버전 모두 사용할 수 있는 베타 API의 사용 중단(deprecation) 시기일 때 진행하는 것이 최선이다. +베타 API의 사용 중단(deprecation) 시기가 끝나고 더 이상 사용될 수 없다면 반드시 대체 API 버전을 사용해야 한다. {{< note >}} -쿠버네티스는 또한 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부 -상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를 -업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다. +비록 쿠버네티스는 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부 +상황에서 이는 불가능하다. 알파 API 버전을 사용하는 경우, 클러스터를 업그레이드해야 할 때에는 +API 변경으로 인해 호환성이 깨지고 업그레이드 전에 기존 오브젝트를 전부 제거해야 하는 상황에 대비하기 위해 +쿠버네티스의 릴리스 정보를 확인하자. {{< /note >}} API 버전 수준 정의에 대한 자세한 내용은 From 2c7b7ef1303b50772980c19c97ad4cf681cb5b34 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Wed, 22 Mar 2023 15:39:15 +0900 Subject: [PATCH 56/69] [ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196) --- .../extend-kubernetes/setup-konnectivity.md | 2 +- .../coarse-parallel-processing-work-queue.md | 10 +- .../fine-parallel-processing-work-queue.md | 12 +- .../job/indexed-parallel-processing-static.md | 11 +- .../docs/tasks/manage-gpus/scheduling-gpus.md | 174 ++++++------------ .../horizontal-pod-autoscale.md | 27 ++- content/ko/docs/tasks/tools/_index.md | 4 +- .../docs/tasks/tools/install-kubectl-linux.md | 10 +- .../tasks/tools/install-kubectl-windows.md | 26 ++- .../ko/docs/tutorials/security/apparmor.md | 2 +- .../tutorials/security/cluster-level-pss.md | 9 +- .../docs/tutorials/security/ns-level-pss.md | 2 +- .../ko/docs/tutorials/services/source-ip.md | 3 +- .../basic-stateful-set.md | 53 +++++- .../expose-external-ip-address.md | 2 +- .../stateless-application/guestbook.md | 2 +- 16 files changed, 203 insertions(+), 146 deletions(-) diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md index 5bc131af19..d4b083f067 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -54,7 +54,7 @@ konnectivity-server에 대한 인증서 및 kubeconfig를 생성하거나 얻는 클러스터 CA 인증서 `/etc/kubernetes/pki/ca.crt`를 사용하여 X.509 인증서를 발급할 수 있다. ```bash -openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr +openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256 SERVER=$(kubectl config view -o jsonpath='{.clusters..server}') kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true diff --git a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md index bd8bf38808..8073ecc3ac 100644 --- a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -244,7 +244,13 @@ gcloud docker -- push gcr.io//job-wq-1 kubectl apply -f ./job.yaml ``` -이제 조금 기다린 다음, 잡을 확인한다. +아래와 같이 시간 제한(timeout)을 설정하고, 잡이 성공할 때까지 기다린다. +```shell +# 조건명은 대소문자를 구분하지 않는다. +kubectl wait --for=condition=complete --timeout=300s job/job-wq-1 +``` + +잡을 확인한다. ```shell kubectl describe jobs/job-wq-1 @@ -285,6 +291,8 @@ Events: 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0 ``` + + 모든 파드가 성공했다. 야호. diff --git a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md index b85f687df7..e582e370a3 100644 --- a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -171,6 +171,7 @@ gcloud docker -- push gcr.io//job-wq-2 따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지 기다린다. + ## 잡 실행 이제 잡을 실행한다. @@ -207,9 +208,18 @@ Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 33s 33s 1 {job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8 +``` +아래와 같이 시간 제한(timeout)을 설정하고, 잡이 성공할 때까지 기다린다. +```shell +# 조건명은 대소문자를 구분하지 않는다. +kubectl wait --for=condition=complete --timeout=300s job/job-wq-2 +``` +```shell kubectl logs pods/job-wq-2-7r7b2 +``` +``` Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f Initial queue state: empty=False Working on banana @@ -217,7 +227,7 @@ Working on date Working on lemon ``` -보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다. +보다시피, 파드 중 하나가 여러 작업 항목을 처리했다. diff --git a/content/ko/docs/tasks/job/indexed-parallel-processing-static.md b/content/ko/docs/tasks/job/indexed-parallel-processing-static.md index f193d23fc9..e5c19ddc12 100644 --- a/content/ko/docs/tasks/job/indexed-parallel-processing-static.md +++ b/content/ko/docs/tasks/job/indexed-parallel-processing-static.md @@ -107,7 +107,14 @@ kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml `.spec.parallelism`가 `.spec.completions`보다 작기 때문에, 컨트롤 플레인은 추가로 파드를 시작하기 전 최초 생성된 파드 중 일부가 완료되기를 기다린다. -잡을 생성했다면, 잠시 기다린 후 진행 상황을 확인한다. +아래와 같이 시간 제한(timeout)을 설정하고, 잡이 성공할 때까지 기다린다. +```shell +# 조건명은 대소문자를 구분하지 않는다. +kubectl wait --for=condition=complete --timeout=300s job/indexed-job +``` + +잡의 상세 설명을 출력하여 성공적으로 수행되었는지 확인한다. + ```shell kubectl describe jobs/indexed-job @@ -182,4 +189,4 @@ kubectl logs indexed-job-fdhq5 # 잡에 속한 파드의 이름에 맞춰 변경 ``` xuq -``` \ No newline at end of file +``` diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 1a98164bd1..4392883102 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -8,50 +8,46 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성 -{{< feature-state state="beta" for_k8s_version="v1.10" >}} - -쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인** -지원을 포함한다. - -이 페이지는 여러 쿠버네티스 버전에서 사용자가 GPU를 활용할 수 있는 방법과 -현재의 제약 사항을 설명한다. - +{{< feature-state state="stable" for_k8s_version="v1.26" >}} +쿠버네티스는 {{< glossary_tooltip text="디바이스 플러그인" term_id="device-plugin" >}}을 사용하여 +AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 여러 노드들에 걸쳐 관리하기 위한 +**안정적인** 지원을 포함한다. +이 페이지는 사용자가 GPU를 활용할 수 있는 방법과, +몇 가지 제한 사항에 대하여 설명한다. ## 디바이스 플러그인 사용하기 -쿠버네티스는 {{< glossary_tooltip text="디바이스 플러그인" term_id="device-plugin" >}}을 구현하여 -파드가 GPU와 같이 특별한 하드웨어 기능에 접근할 수 있게 한다. +쿠버네티스는 디바이스 플러그인을 구현하여 파드가 GPU와 같이 특별한 하드웨어 기능에 접근할 수 있게 한다. + +{{% thirdparty-content %}} 관리자는 해당하는 하드웨어 벤더의 GPU 드라이버를 노드에 설치해야 하며, GPU 벤더가 제공하는 디바이스 플러그인을 -실행해야 한다. +실행해야 한다. 다음은 몇몇 벤더의 지침에 대한 웹페이지이다. -* [AMD](#amd-gpu-디바이스-플러그인-배치하기) -* [NVIDIA](#nvidia-gpu-디바이스-플러그인-배치하기) +* [AMD](https://github.com/RadeonOpenCompute/k8s-device-plugin#deployment) +* [Intel](https://intel.github.io/intel-device-plugins-for-kubernetes/cmd/gpu_plugin/README.html) +* [NVIDIA](https://github.com/NVIDIA/k8s-device-plugin#quick-start) -위의 조건이 만족되면, 쿠버네티스는 `amd.com/gpu` 또는 -`nvidia.com/gpu` 를 스케줄 가능한 리소스로써 노출시킨다. +플러그인을 한 번 설치하고 나면, 클러스터는 `amd.com/gpu` 또는 `nvidia.com/gpu`를 스케줄 가능한 리소스로써 노출시킨다. -사용자는 이 GPU들을 `cpu` 나 `memory` 를 요청하는 방식과 동일하게 -`.com/gpu` 를 요청함으로써 컨테이너에서 활용할 수 있다. -그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의 -제약이 있다. +사용자는 이 GPU들을 `cpu`나 `memory`를 요청하는 방식과 동일하게 +GPU 자원을 요청함으로써 컨테이너에서 활용할 수 있다. +그러나 리소스의 요구 사항을 명시하는 방식에 +약간의 제약이 있다. -- GPU는 `limits` 섹션에서만 명시되는 것을 가정한다. 그 의미는 다음과 같다. - * 쿠버네티스는 limits를 requests의 기본 값으로 사용하게 되므로 - 사용자는 GPU `limits` 를 명시할 때 `requests` 명시하지 않아도 된다. - * 사용자는 `limits` 과 `requests` 를 모두 명시할 수 있지만, 두 값은 - 동일해야 한다. - * 사용자는 `limits` 명시 없이는 GPU `requests` 를 명시할 수 없다. -- 컨테이너들(그리고 파드들)은 GPU를 공유하지 않는다. GPU에 대한 초과 할당(overcommitting)은 제공되지 않는다. -- 각 컨테이너는 하나 이상의 GPU를 요청할 수 있다. GPU의 일부(fraction)를 요청하는 것은 - 불가능하다. +GPU는 `limits` 섹션에서만 명시되는 것을 가정한다. 그 의미는 다음과 같다. +* 쿠버네티스는 limits를 requests의 기본 값으로 사용하게 되므로 + 사용자는 GPU `limits` 를 명시할 때 `requests` 명시하지 않아도 된다. +* 사용자는 `limits` 과 `requests` 를 모두 명시할 수 있지만, 두 값은 + 동일해야 한다. +* 사용자는 `limits` 명시 없이는 GPU `requests` 를 명시할 수 없다. -다음은 한 예제를 보여준다. +다음은 GPU를 요청하는 파드에 대한 예제 매니페스트를 보여준다. ```yaml apiVersion: v1 @@ -61,81 +57,12 @@ metadata: spec: restartPolicy: OnFailure containers: - - name: cuda-vector-add - # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile - image: "registry.k8s.io/cuda-vector-add:v0.1" + - name: example-vector-add + image: "registry.example/example-vector-add:v42" resources: limits: - nvidia.com/gpu: 1 # GPU 1개 요청하기 -``` - -### AMD GPU 디바이스 플러그인 배치하기 - -[공식 AMD GPU 디바이스 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)에는 -다음의 요구 사항이 있다. - -- 쿠버네티스 노드들에는 AMD GPU 리눅스 드라이버가 미리 설치되어 있어야 한다. - -클러스터가 실행 중이고 위의 요구 사항이 만족된 후, AMD 디바이스 플러그인을 배치하기 위해서는 -아래 명령어를 실행한다. -```shell -kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml -``` - -[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)에 이슈를 로깅하여 -해당 서드 파티 디바이스 플러그인에 대한 이슈를 리포트할 수 있다. - -### NVIDIA GPU 디바이스 플러그인 배치하기 - -현재는 NVIDIA GPU에 대한 두 개의 디바이스 플러그인 구현체가 있다. - -#### 공식 NVIDIA GPU 디바이스 플러그인 - -[공식 NVIDIA GPU 디바이스 플러그인](https://github.com/NVIDIA/k8s-device-plugin)은 -다음의 요구 사항을 가진다. - -- 쿠버네티스 노드에는 NVIDIA 드라이버가 미리 설치되어 있어야 한다. -- 쿠버네티스 노드에는 [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)이 미리 설치되어 있어야 한다. -- Kubelet은 자신의 컨테이너 런타임으로 도커를 사용해야 한다. -- 도커는 runc 대신 `nvidia-container-runtime` 이 [기본 런타임](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)으로 - 설정되어야 한다. -- NVIDIA 드라이버의 버전은 조건 ~= 384.81을 만족해야 한다. - -클러스터가 실행 중이고 위의 요구 사항이 만족된 후, NVIDIA 디바이스 플러그인을 배치하기 위해서는 -아래 명령어를 실행한다. - -```shell -kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml -``` - -[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)에 이슈를 로깅하여 -해당 서드 파티 디바이스 플러그인에 대한 이슈를 리포트할 수 있다. - -#### GCE에서 사용되는 NVIDIA GPU 디바이스 플러그인 - -[GCE에서 사용되는 NVIDIA GPU 디바이스 플러그인](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)은 -nvidia-docker의 사용이 필수가 아니며 컨테이너 런타임 인터페이스(CRI)에 -호환되는 다른 컨테이너 런타임을 사용할 수 있다. 해당 사항은 -[컨테이너에 최적화된 OS](https://cloud.google.com/container-optimized-os/)에서 테스트되었고, -우분투 1.9 이후 버전에 대한 실험적인 코드를 가지고 있다. - -사용자는 다음 커맨드를 사용하여 NVIDIA 드라이버와 디바이스 플러그인을 설치할 수 있다. - -```shell -# 컨테이너에 최적회된 OS에 NVIDIA 드라이버 설치: -kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml - -# 우분투에 NVIDIA 드라이버 설치(실험적): -kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml - -# 디바이스 플러그인 설치: -kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml -``` - -[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators)에 이슈를 로깅하여 -해당 서드 파티 디바이스 플러그인에 대한 이슈를 리포트할 수 있다. - -Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)를 게재하고 있다. + gpu-vendor.example/example-gpu: 1 # 1 GPU 요청 +``` ## 다른 타입의 GPU들을 포함하는 클러스터 @@ -147,10 +74,13 @@ Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud ```shell # 노드가 가진 가속기 타입에 따라 레이블을 단다. -kubectl label nodes accelerator=nvidia-tesla-k80 -kubectl label nodes accelerator=nvidia-tesla-p100 +kubectl label nodes node1 accelerator=example-gpu-x100 +kubectl label nodes node2 accelerator=other-gpu-k915 ``` +`accelerator` 레이블 키를 `accelerator`로 지정한 것은 그저 예시일 뿐이며, +선호하는 다른 레이블 키를 사용할 수 있다. + ## 노드 레이블링 자동화 {#node-labeller} 만약 AMD GPU 디바이스를 사용하고 있다면, @@ -179,19 +109,18 @@ kubectl describe node cluster-node-23 ``` ``` - Name: cluster-node-23 - Roles: - Labels: beta.amd.com/gpu.cu-count.64=1 - beta.amd.com/gpu.device-id.6860=1 - beta.amd.com/gpu.family.AI=1 - beta.amd.com/gpu.simd-count.256=1 - beta.amd.com/gpu.vram.16G=1 - beta.kubernetes.io/arch=amd64 - beta.kubernetes.io/os=linux - kubernetes.io/hostname=cluster-node-23 - Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock - node.alpha.kubernetes.io/ttl: 0 - … +Name: cluster-node-23 +Roles: +Labels: beta.amd.com/gpu.cu-count.64=1 + beta.amd.com/gpu.device-id.6860=1 + beta.amd.com/gpu.family.AI=1 + beta.amd.com/gpu.simd-count.256=1 + beta.amd.com/gpu.vram.16G=1 + kubernetes.io/arch=amd64 + kubernetes.io/os=linux + kubernetes.io/hostname=cluster-node-23 +Annotations: node.alpha.kubernetes.io/ttl: 0 +… ``` 노드 레이블러가 사용된 경우, GPU 타입을 파드 스펙에 명시할 수 있다. @@ -210,9 +139,14 @@ spec: resources: limits: nvidia.com/gpu: 1 - nodeSelector: - accelerator: nvidia-tesla-p100 # 또는 nvidia-tesla-k80 등. + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + – matchExpressions: + – key: beta.amd.com/gpu.family.AI # Arctic Islands GPU family + operator: Exist ``` -이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록 +이것은 사용자가 지정한 GPU 타입을 가진 노드에 파드가 스케줄 되도록 만든다. 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 cc9db37d6a..13c4a99fb4 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -47,7 +47,30 @@ Horizontal Pod Autoscaling을 활용하는 ## HorizontalPodAutoscaler는 어떻게 작동하는가? -{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}} +{{< mermaid >}} +graph BT + +hpa[Horizontal Pod Autoscaler] --> scale[Scale] + +subgraph rc[RC / Deployment] + scale +end + +scale -.-> pod1[Pod 1] +scale -.-> pod2[Pod 2] +scale -.-> pod3[Pod N] + +classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +class hpa hpa; +class rc rc; +class scale scale; +class pod1,pod2,pod3 pod +{{< /mermaid >}} + +그림 1. HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다. 쿠버네티스는 Horizontal Pod Autoscaling을 간헐적으로(intermittently) 실행되는 @@ -139,7 +162,7 @@ CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히 기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는 특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는 시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지 -않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로 +않았고 시작 이후 짧은 시간 내에 파드가 준비 상태로 전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다. 이 값은 `--horizontal-pod-autoscaler-initial-readiness-delay` 플래그로 설정되며, 기본값은 30초 이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면, diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 990a9fd99b..d5babfa70f 100644 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -35,8 +35,8 @@ kind를 시작하고 실행하기 위해 수행해야 하는 작업을 보여준 ## minikube `kind` 와 마찬가지로, [`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는 -도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서 -단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을 +도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서 올인원 방식 또는 +복수 개의 노드로 쿠버네티스 클러스터를 실행하여, 쿠버네티스를 사용해보거나 일상적인 개발 작업을 수행할 수 있다. 도구 설치에 중점을 두고 있다면 공식 사이트에서의 diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index 8fc7aa844b..0473673121 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -120,13 +120,13 @@ card: 2. 구글 클라우드 공개 사이닝 키를 다운로드한다. ```shell - sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` 3. 쿠버네티스 `apt` 리포지터리를 추가한다. ```shell - echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` 4. 새 리포지터리의 `apt` 패키지 색인을 업데이트하고 kubectl을 설치한다. @@ -135,6 +135,10 @@ card: sudo apt-get update sudo apt-get install -y kubectl ``` +{{< note >}} +Debian 12 또는 Ubuntu 22.04 이전 릴리스에서는 기본적으로 `/etc/apt/keyrings` 파일이 존재하지 않는다. +필요할 경우, 읽기 권한은 모두에게 부여되지만 쓰기 권한은 관리자만 갖도록 해당 디렉토리를 생성한다. +{{< /note >}} {{% /tab %}} @@ -146,7 +150,7 @@ name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch enabled=1 gpgcheck=1 -gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF sudo yum install -y kubectl ``` diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md index 2a381a3ee9..305d6d9583 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-windows.md +++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md @@ -20,7 +20,7 @@ card: 다음과 같은 방법으로 윈도우에 kubectl을 설치할 수 있다. - [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows) -- [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop) +- [Chocolatey, Scoop, 또는 winget을 사용하여 윈도우에 설치](#install-nonstandard-package-tools) ### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows} @@ -30,7 +30,7 @@ card: 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. ```powershell - curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe" + curl.exe -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe" ``` {{< note >}} @@ -42,7 +42,11 @@ card: `kubectl` 체크섬 파일을 다운로드한다. ```powershell +<<<<<<< HEAD curl -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe.sha256" +======= + curl.exe -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256" +>>>>>>> e54c13c4a4 ([ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196)) ``` `kubectl` 바이너리를 체크섬 파일을 통해 검증한다. @@ -78,9 +82,9 @@ card: 도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 `PATH` 항목 앞에 `PATH` 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다. {{< /note >}} -### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치 {#install-on-windows-using-chocolatey-or-scoop} +### Chocolatey, Scoop, 또는 winget을 사용하여 윈도우에 설치 {#install-nonstandard-package-tools} -1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. +1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자, [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램, [winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/) 패키지 관리자를 사용할 수 있다. {{< tabs name="kubectl_win_install" >}} {{% tab name="choco" %}} @@ -93,9 +97,13 @@ card: scoop install kubectl ``` {{% /tab %}} + {{% tab name="winget" %}} + ```powershell + winget install -e --id Kubernetes.kubectl + ``` + {{% /tab %}} {{< /tabs >}} - 1. 설치한 버전이 최신 버전인지 확인한다. ```powershell @@ -152,7 +160,11 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제 1. 다음 명령으로 최신 릴리스를 다운로드한다. ```powershell +<<<<<<< HEAD curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe" +======= + curl.exe -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe" +>>>>>>> e54c13c4a4 ([ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196)) ``` 1. 바이너리를 검증한다. (선택 사항) @@ -160,7 +172,11 @@ kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제 `kubectl-convert` 체크섬(checksum) 파일을 다운로드한다. ```powershell +<<<<<<< HEAD curl -LO "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl-convert.exe.sha256" +======= + curl.exe -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256" +>>>>>>> e54c13c4a4 ([ko] Update outdated files in dev-1.26-ko.1 (M165-M173,M189-M196)) ``` `kubectl-convert` 바이너리를 체크섬 파일을 통해 검증한다. diff --git a/content/ko/docs/tutorials/security/apparmor.md b/content/ko/docs/tutorials/security/apparmor.md index c04d05e24f..fb6b0622e4 100644 --- a/content/ko/docs/tutorials/security/apparmor.md +++ b/content/ko/docs/tutorials/security/apparmor.md @@ -152,7 +152,7 @@ container.apparmor.security.beta.kubernetes.io/: kubectl get events | grep Created ``` ``` -22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]apparmor=k8s-apparmor-example-deny-write] +22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] ``` 컨테이너의 루트 프로세스가 올바른 프로파일로 실행되는지는 proc attr을 확인하여 직접 검증할 수 있다. diff --git a/content/ko/docs/tutorials/security/cluster-level-pss.md b/content/ko/docs/tutorials/security/cluster-level-pss.md index 97c8c1aace..7b5bb7be80 100644 --- a/content/ko/docs/tutorials/security/cluster-level-pss.md +++ b/content/ko/docs/tutorials/security/cluster-level-pss.md @@ -187,7 +187,7 @@ weight: 10 plugins: - name: PodSecurity configuration: - apiVersion: pod-security.admission.config.k8s.io/v1beta1 + apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" @@ -203,6 +203,13 @@ weight: 10 EOF ``` + {{< note >}} + `pod-security.admission.config.k8s.io/v1` 설정은 쿠버네티스 v1.25 이상을 필요로 한다. + 쿠버네티스 v1.23 과 v1.24의 경우, [v1beta1](https://v1-24.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)을 사용한다. + 쿠버네티스 v1.22의 경우, [v1alpha1](https://v1-22.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)을 사용한다. + {{< /note >}} + + 1. API 서버가 클러스터 생성 과정에서 이 파일을 처리할 수 있도록 구성한다. ``` diff --git a/content/ko/docs/tutorials/security/ns-level-pss.md b/content/ko/docs/tutorials/security/ns-level-pss.md index b7c21e0404..aefb3f1cdc 100644 --- a/content/ko/docs/tutorials/security/ns-level-pss.md +++ b/content/ko/docs/tutorials/security/ns-level-pss.md @@ -155,7 +155,7 @@ namespace/example created ## 정리하기 -`kind delete cluster -name psa-ns-level` 명령을 실행하여 생성했던 클러스터를 삭제한다. +`kind delete cluster --name psa-ns-level` 명령을 실행하여 생성했던 클러스터를 삭제한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 7617e33685..75ba48d0c7 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -2,6 +2,7 @@ title: 소스 IP 주소 이용하기 content_type: tutorial min-kubernetes-server-version: v1.5 +weight: 40 --- @@ -415,5 +416,5 @@ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} -* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 더 자세히 본다. +* [서비스를 통한 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 더 자세히 본다. * [외부 로드밸런서 생성](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/) 방법을 본다. 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 b961580a73..b33e84e63a 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -131,6 +131,11 @@ web-1 1/1 Running 0 18s _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고) 및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에는 시작되지 않음에 주의한다. +{{< note >}} +스테이트풀셋에서 각 파드에 할당되는 정수값의 순서를 설정하려면, +[시작 순서](/ko/docs/concepts/workloads/controllers/statefulset/#시작-순서)를 확인한다. +{{< /note >}} + ## 스테이트풀셋 안에 파드 스테이트풀셋 안에 파드는 고유한 순번과 동일한 네트워크 신원을 가진다. @@ -1202,12 +1207,54 @@ web-3 0/1 Terminating 0 9m kubectl delete svc nginx ``` +이 튜토리얼에서 퍼시스턴트볼륨으로 사용했던 영구 스토리지를 삭제한다. +```shell +kubectl get pvc +``` +``` +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE +www-web-0 Bound pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO standard 25m +www-web-1 Bound pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO standard 24m +www-web-2 Bound pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO standard 15m +www-web-3 Bound pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO standard 15m +www-web-4 Bound pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO standard 14m +``` + +```shell +kubectl get pv +``` +``` +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE +pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO Delete Bound default/www-web-3 standard 15m +pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO Delete Bound default/www-web-0 standard 25m +pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO Delete Bound default/www-web-4 standard 14m +pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO Delete Bound default/www-web-1 standard 24m +pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO Delete Bound default/www-web-2 standard 15m +``` + +```shell +kubectl delete pvc www-web-0 www-web-1 www-web-2 www-web-3 www-web-4 +``` + +``` +persistentvolumeclaim "www-web-0" deleted +persistentvolumeclaim "www-web-1" deleted +persistentvolumeclaim "www-web-2" deleted +persistentvolumeclaim "www-web-3" deleted +persistentvolumeclaim "www-web-4" deleted +``` + +```shell +kubectl get pvc +``` + +``` +No resources found in default namespace. +``` {{< note >}} 이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 퍼시스턴트 스토리지 미디어도 삭제해야 한다. - - 모든 스토리지를 반환하도록 환경, 스토리지 설정과 프로비저닝 방법에 따른 단계를 따르자. -{{< /note >}} +{{< /note >}} \ No newline at end of file diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 71c0409fea..25177c6fa7 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -174,5 +174,5 @@ kubectl delete deployment hello-world ## {{% heading "whatsnext" %}} -[애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 +[애플리케이션과 서비스 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해 더 배워 본다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 24137efece..07557d3500 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -418,5 +418,5 @@ Google Compute Engine 또는 Google Kubernetes Engine * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기 -* [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 +* [애플리케이션과 서비스 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해 더 알아보기 * [자원 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)에 대해 더 알아보기 From cbcf4e7203c4503841d5d3a0e5bd39430f3e2fe4 Mon Sep 17 00:00:00 2001 From: 9bany Date: Tue, 23 May 2023 18:34:37 +0700 Subject: [PATCH 57/69] fix/ko-replace-all-references-storage-to-k8s --- .../production-environment/tools/kubeadm/install-kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 596b10b8b8..22fe417acd 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 @@ -249,7 +249,7 @@ curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL 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/${ARCH}/{kubeadm,kubelet,kubectl} +sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} sudo chmod +x {kubeadm,kubelet,kubectl} RELEASE_VERSION="v0.4.0" From 3f0f2afb2bb77ee85d0e74607a3d1d415cedfca6 Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Tue, 23 May 2023 21:56:37 +0900 Subject: [PATCH 58/69] [ko] Update outdated files in dev-1.26.-ko.1 [M27] --- .../compute-storage-net/_index.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/_index.md index a895ea8beb..102894d364 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/_index.md @@ -1,4 +1,43 @@ --- title: 컴퓨트, 스토리지 및 네트워킹 익스텐션 weight: 30 +no_list: true --- + +해당 섹션은 쿠버네티스 자체에 포함되어있지 않지만 클러스터에 설정할 수 있는 익스텐션들에 대해 다룬다. +이러한 익스텐션을 활용하여 클러스터의 노드를 향상시키거나, +파드들을 연결시키는 네트워크 장치를 제공할 수 있다. + +* [CSI](/ko/docs/concepts/storage/volumes/#csi) 와 [FlexVolume](/ko/docs/concepts/storage/volumes/#flexvolume) 스토리지 플러그인 + + {{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}} (CSI) 플러그인은 + 새로운 종류의 볼륨을 지원하도록 쿠버네티스를 확장할 수 있게 해준다. + 볼륨은 내구성 높은 외부 스토리지에 연결되거나, 일시적인 스토리지를 제공하거나, + 파일시스템 패러다임을 토대로 정보에 대한 읽기 전용 인터페이스를 제공할 수도 있다. + + 또한 쿠버네티스는 (CSI를 권장하며) v1.23부터 사용 중단된 + [FlexVolume](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) 플러그인에 대한 지원도 포함한다. + + FlexVolume 플러그인은 쿠버네티스에서 네이티브하게 + 지원하지 않는 볼륨 종류도 마운트할 수 있도록 해준다. + FlexVolume 스토리지에 의존하는 파드를 실행하는 경우 kubelet은 바이너리 플러그인을 호출하여 볼륨을 마운트한다. + 아카이브된 [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) + 디자인 제안은 이러한 접근방법에 대한 자세한 설명을 포함하고 있다. + + 스토리지 플러그인에 대한 전반적인 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 + 찾을 수 있다. + +* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + + 장치 플러그인은 노드에서 (`cpu`와 `memory`와 같은 내장 노드 리소스에서 추가로) + 새로운 노드 장치(Node facility)를 발견할 수 있게 해주며, + 이러한 커스텀 노드 장치를 요청하는 파드들에게 이를 제공한다. + +* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + + 네트워크 플러그인을 통해 쿠버네티스는 다양한 네트워크 토폴로지 및 기술을 활용할 수 있게 된다. + 제대로 동작하는 파드 네트워크을 구성하고 쿠버네티스 네트워크 모델의 다양한 측면을 지원하기 위해 + 쿠버네티스 클러스터는 *네트워크 플러그인*을 필요로 한다. + + 쿠버네티스 {{< skew currentVersion >}}은 {{< glossary_tooltip text="CNI" term_id="cni" >}} + 네트워크 플러그인들에 호환된다. From 31795a993f15bf9862ccfc48f1fdcab91252de8c Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Thu, 25 May 2023 00:02:05 +0900 Subject: [PATCH 59/69] [ko] Update outdated files in dev-1.26.-ko.1 [M23] --- .../docs/concepts/extend-kubernetes/_index.md | 295 +++++++++++------- .../configure-multiple-schedulers.md | 2 +- 2 files changed, 176 insertions(+), 121 deletions(-) diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index 57adc7c378..bf5f306e91 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -28,41 +28,38 @@ no_list: true 어떤 익스텐션(extension) 포인트와 패턴이 있는지, 그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다. - - -## 개요 - 사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 -포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 -나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. +포함하는 [구성](#구성)과 추가적인 프로그램, 추가적인 네트워크 서비스, +또는 둘 다의 실행을 요구하는 [익스텐션](#익스텐션)으로 나눌 수 있다. +이 문서는 주로 _익스텐션_ 에 관한 것이다. + + ## 구성 -*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 +*구성 파일* 및 *명령행 인자* 는 온라인 문서의 [레퍼런스](/ko/docs/reference/) 섹션에 각 바이너리 별로 문서화되어 있다. -* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) -* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) -* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) -* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). +* [`kube-apiserver`](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [`kube-scheduler`](/docs/reference/command-line-tools-reference/kube-scheduler/). +* [`kubelet`](/docs/reference/command-line-tools-reference/kubelet/) +* [`kube-proxy`](/docs/reference/command-line-tools-reference/kube-proxy/) -호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 -플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 -가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 -쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 +호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 +명령행 인자 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 +가능하더라도 일반적으로 클러스터 오퍼레이터를 통해서만 변경될 수 있다. 또한 향후 +쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. -[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), -[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), -[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 -역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 -*빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 -일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 -선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 -구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 -경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 -사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다. +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), +[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 +역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 빌트인 *정책 API(Policy API)* 는 선언적으로 구성된 정책 설정을 제공하는 내장 쿠버네티스 API이다. API는 +일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용할 수도 있다. +빌트인 정책 API는 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 따른다. +[안정적인](/ko/docs/reference/using-api/#api-versioning) 정책 API를 사용하는 경우 +다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)의 혜택을 볼 수 있다. +이러한 이유로 인해 적절한 상황에서는 정책 API는 *구성 파일* 과 *명령행 인자* 보다 권장된다. ## 익스텐션 @@ -73,7 +70,7 @@ no_list: true 이러한 클러스터들은 미리 설치된 익스텐션을 포함한다. 결과적으로 대부분의 쿠버네티스 사용자는 익스텐션을 설치할 필요가 없고, 새로운 익스텐션을 만들 필요가 있는 사용자는 더 적다. -## 익스텐션 패턴 +### 익스텐션 패턴 쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다. 쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다. @@ -82,125 +79,161 @@ no_list: true 자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든 쿠버네티스 클러스터에서 작동한다. -쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다. +쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 패턴이라고 한다. 컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음 오브젝트의 `.status`를 업데이트 한다. -컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때 -이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 *웹훅 백엔드* 라고 한다. 컨트롤러와 -마찬가지로 웹훅은 장애 지점을 추가한다. +컨트롤러는 쿠버네티스 API의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때, +쿠버네티스는 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스는 *웹훅 백엔드* 라고 한다. +커스텀 컨트롤러와 마찬가지로 웹훅은 새로운 장애 지점이 된다. + +{{< note >}} +쿠버네티스와 별개로 "웹훅"이라는 용어는 일반적으로 비동기 알림 메커니즘을 의미한다. +이때 웹훅 호출은 다른 시스템 혹은 컴포넌트로 보내지는 단방향적인 알림의 역할을 수행한다. +쿠버네티스 생태계에서는 동기적인 HTTP 호출도 +"웹훅"이라고 불린다. +{{< /note >}} 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. -*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. -바이너리 플러그인은 kubelet(예: -[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과 -[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 -kubectl에서 사용한다. - -아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 -보여주는 다이어그램이다. - - -![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png) +그 대안인 *바이너리 플러그인* 모델에서는 쿠버네티스에서 바이너리(프로그램)를 실행한다. +바이너리 플러그인은 kubelet(예: [CSI 스토리지 플러그인](https://kubernetes-csi.github.io/docs/)과 +[CNI 네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)) 및 +kubectl에서 사용된다. ([플러그인으로 kubectl 확장](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 참고하자.) ## 익스텐션 포인트 -이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. +이 다이어그램은 쿠버네티스 클러스터의 익스텐션 포인트와 +그에 접근하는 클라이언트를 보여준다. - -![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png) + -1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. - [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. - 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +{{< figure src="/docs/concepts/extend-kubernetes/extension-points.png" + alt="쿠버네티스의 익스텐션 포인트를 7개의 숫자 심볼로 표시" + class="diagram-large" caption="쿠버네티스 익스텐션 포인트" >}} -1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, - 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 +#### 그림의 핵심 + +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [플러그인](#client-extensions)을 통해 + 클라이언트의 행동을 커스터마이징할 수 있다. 다양한 클라이언트들에 적용될 수 있는 일반적인 익스텐션도 있으며, + `kubectl`을 확장하기 위한 구체적인 방법도 존재한다. + +1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, + 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다. -1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 - 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 - 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 - *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. - 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. +1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pod`와 같은 *빌트인 리소스 종류* 는 + 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. + 쿠버네티스 API를 확장하는 것에 대한 내용은 [API 익스텐션](#api-익스텐션)에 설명되어 있다. -1. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 - 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다. +1. 쿠버네티스 스케줄러는 파드를 어느 노드에 배치할지 + [결정](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)한다. 스케줄링을 확장하는 몇 가지 + 방법이 있으며, 이는 [스케줄링 익스텐션](#스케줄링-익스텐션) 섹션에 설명되어 있다. -1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 - 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. +1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 + {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라는 + 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. + [새로운 API와 자동화의 결합](#combining-new-apis-with-automation)과 + [빌트인 리소스 변경](#빌트인-리소스-변경)에 설명되어 있다. -1. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 - 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 +1. kubelet은 서버(노드)에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 + 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. -1. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 - [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다. +1. [장치 플러그인](#device-plugins)을 사용하여 커스텀 하드웨어나 노드에 설치된 특수한 장치와 통합하고, + 클러스터에서 실행 중인 파드에서 사용 가능하도록 할 수 있다. + kubelet을 통해 장치 플러그인를 조작할 수 있다. -어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 + kubelet은 컨테이너의 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 + 마운트 및 마운트 해제한다. + [스토리지 플러그인](#storage-plugins)을 사용하여 새로운 종류의 스토리지와 + 다른 볼륨 타입에 대한 지원을 추가할 수 있다. + + +#### 익스텐션 포인트 선택 순서도 {#extension-flowchart} + +어디서부터 시작해야 할지 모르겠다면, 이 순서도가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. - -![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png) + + +{{< figure src="/docs/concepts/extend-kubernetes/flowchart.png" + alt="유스케이스에 따른 질문과 가이드를 포함하는 순서도. 초록색 원은 예를 뜻하고, 빨간색 원은 아니오를 뜻함" + class="diagram-large" caption="익스텐션 방법 선택을 가이드하기 위한 순서도" >}} + +--- + +## 클라이언트 익스텐션 {#client-extensions} + +kubectl을 위한 플러그인은 별도의 바이너리로 특정한 하위 명령어를 추가하거나 변경해준다. +또한 `kubectl` 은 [자격증명 플러그인](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)과 통합될 수도 있다. +이러한 익스텐션은 개별 사용자의 로컬 환경에만 영향을 주기 때문에 거시적인 정책을 강제할 수 없다. + +`kubectl` 자체를 확장하는 방법은 [플러그인으로 kubectl 확장](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 설명되어 있다. ## API 익스텐션 -### 사용자 정의 유형 +### 커스텀 리소스 데피니션 새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 -쿠버네티스에 커스텀 리소스를 추가하자. - -애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다. - +쿠버네티스에 _커스텀 리소스_ 를 추가하자. 커스텀 리소스에 대한 자세한 내용은 -[커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다. +[커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 개념 가이드를 참고하길 바란다. +### API 애그리게이션 레이어 -### 새로운 API와 자동화의 결합 +쿠버네티스의 [API 애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 +[메트릭](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/) 등을 목적으로 +쿠버네티스 API를 추가적인 서비스와 통합할 수 있다. -사용자 정의 리소스 API와 컨트롤 루프의 조합을 -[오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 -특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 -사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. +### 새로운 API와 자동화의 결합 {#combining-new-apis-with-automation} + +사용자 정의 리소스 API와 컨트롤 루프의 조합을 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 패턴이라고 한다. +만약 컨트롤러가 의도한 상태에 따라 인프라스트럭쳐를 배포하는 인간 오퍼레이터의 역할을 대신하고 있다면, +컨트롤러는 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}}을 따르고 있을지도 모른다. +오퍼레이터 패턴은 특정 애플리케이션을 관리하는 데 사용된다. +주로 이러한 애플리케이션들은 상태를 지니며 상태를 어떻게 관리해야 하는지에 관한 주의를 요한다. + +또한 스토리지와 같은 다른 리소스를 관리하거나 접근 제어 제한 등의 정책을 정의하기 위해 +커스텀 API와 제어 루프를 만드는 것도 가능하다. ### 빌트인 리소스 변경 -사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 +사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. -API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API -접근 익스텐션은 영향을 준다. +API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 +_API 접근 익스텐션_ 은 영향을 준다. -### API 접근 익스텐션 +## API 접근 익스텐션 -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 -다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 -대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 +요청이 쿠버네티스 API 서버에 도달하면 먼저 _인증_ 이 되고, 그런 다음 _인가_ 된 후 +다양한 유형의 _어드미션 컨트롤_ 을 거치게 된다. (사실, 일부 요청은 인증되지 않고 특별한 과정을 거친다.) +이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. -이러한 각 단계는 익스텐션 포인트를 제공한다. - -쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 -있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 -확인할 수 있다(웹훅). 이러한 방법은 모두 -[인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. +쿠버네티스의 인증/인가 흐름의 각 단계는 익스텐션 포인트를 제공한다. ### 인증 -[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 +[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다. -쿠버네티스는 몇 가지 빌트인 인증 방법과 -필요에 맞지 않는 경우 -[인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. +쿠버네티스는 몇 가지 빌트인 인증 방법을 지원한다. +이러한 방법이 사용자 요구 사항을 충족시키지 못한다면 +인증 프록시 뒤에 위치하면서 `Authorization:` 헤더로 받은 토큰을 원격 서비스로 보내 검증받는 +방법([인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication))도 존재하므로, 참고하길 바란다. ### 인가 [인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 -작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 -인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 +작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. + +빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 +[인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. ### 동적 어드미션 컨트롤 @@ -214,32 +247,43 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 * 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. + 어떤 어드미션 웹훅은 쿠버네티스에 의해 처리되기 전에 들어오는 요청의 데이터에 변경을 가할 수도 있다. ## 인프라스트럭처 익스텐션 -### 스토리지 플러그인 +### 장치 플러그인 {#device-plugins} -[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 -사용하면 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이 -볼륨 유형을 마운트 할 수 있다. +_장치 플러그인_ 은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 +통해 (CPU 및 메모리와 같은 빌트인 자원 외에 추가적으로) 새로운 노드 리소스를 +발견할 수 있게 해준다. -FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 -추천하는 방식이다. 자세한 정보는 +### 스토리지 플러그인 {#storage-plugins} + +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}} (CSI) 플러그인은 +새로운 종류의 볼륨을 지원하도록 쿠버네티스를 확장할 수 있게 해준다. +볼륨은 내구성 높은 외부 스토리지에 연결되거나, 일시적인 스토리지를 제공하거나, +파일시스템 패러다임을 토대로 정보에 대한 읽기 전용 인터페이스를 제공할 수도 있다. + +또한 쿠버네티스는 (CSI를 권장하며) v1.23부터 사용 중단된 +[FlexVolume](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) 플러그인에 대한 지원도 포함한다. + +FlexVolume 플러그인은 쿠버네티스에서 네이티브하게 지원하지 않는 볼륨 종류도 마운트할 수 있도록 해준다. +FlexVolume 스토리지에 의존하는 파드를 실행하는 경우 kubelet은 바이너리 플러그인을 호출하여 볼륨을 마운트한다. +아카이브된 [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) 디자인 제안은 이러한 접근방법에 대한 자세한 설명을 포함하고 있다. + +스토리지 플러그인에 대한 전반적인 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다. -### 장치 플러그인 - -장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 -통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 -발견할 수 있게 해준다. - ### 네트워크 플러그인 -노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) -을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. +제대로 동작하는 파드 네트워크와 쿠버네티스 네트워크 모델의 다양한 측면을 지원하기 위해 +쿠버네티스 클러스터는 _네트워크 플러그인_ 을 필요로 한다. -### 스케줄러 익스텐션 +[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 +쿠버네티스는 다양한 네트워크 토폴로지 및 기술을 활용할 수 있게 된다. + +### 스케줄링 익스텐션 스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 @@ -250,19 +294,30 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou 이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 필요가 없다는 것을 알게 된다. -스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가 -파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는 -[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을 -지원한다. +어떤 [스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins)을 활성화시킬지 제어하거나, +플러그인들을 다른 이름의 [스케줄러 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)과 연결지을 수도 있다. +kube-scheduler의 [익스텐션 포인트](/docs/concepts/scheduling-eviction/scheduling-framework/#extension-points) 중 +하나 이상과 통합되는 플러그인을 직접 작성할 수도 있다. + +마지막으로 빌트인 `kube-scheduler` 컴포넌트는 원격 HTTP 백엔드 (스케줄러 익스텐션)에서 +kube-scheduler가 파드를 위해 선택한 노드를 +필터링하고 우선하도록 지정할 수 있도록 하는 +[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을 지원한다. + +{{< note >}} +노드 필터링과 노트 우선순위에 영향을 미치는 것은 +스케줄러 인스텐션 웹훅을 통해서만 가능하다. +다른 익스텐션 포인트는 웹훅 통합으로 제공되지 않는다. +{{< /note >}} ## {{% heading "whatsnext" %}} - -* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 -* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 * 인프라스트럭처 익스텐션에 대해 더 알아보기 - * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * CSI [스토리지 플러그인](https://kubernetes-csi.github.io/docs/) * [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 +* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 +* [익스텐션 API 서버](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에 대해 알아보기 +* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 * [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 - diff --git a/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index c2e2c83e9a..6f1e62f172 100644 --- a/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md +++ b/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -214,6 +214,6 @@ kubectl edit clusterrole system:kube-scheduler kubectl get events ``` 또한, 관련된 컨트롤 플레인 노드들의 스태틱 파드 매니페스트를 수정하면 클러스터의 메인 스케줄러로 -[사용자 정의 스케줄러 구성](/ko/docs/reference/scheduling/config/#multiple-profiles) +[사용자 정의 스케줄러 구성](/ko/docs/reference/scheduling/config/#여러-프로파일) 또는 사용자 정의 컨테이너 이미지를 사용할 수도 있다. From 72549f240a9532fabab3a5192b47a1b7d83454e4 Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Thu, 25 May 2023 00:10:10 +0900 Subject: [PATCH 60/69] [ko] Update outdated files in dev-1.26.-ko.1 [M24-26] --- .../extend-kubernetes/api-extension/_index.md | 2 +- .../api-extension/apiserver-aggregation.md | 21 ++- .../api-extension/custom-resources.md | 130 ++++++++++++------ 3 files changed, 103 insertions(+), 50 deletions(-) diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md index 5701f2d0c5..e784981667 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -1,4 +1,4 @@ --- title: 쿠버네티스 API 확장하기 -weight: 20 +weight: 30 --- diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index d438c324d7..ee4a838457 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -10,18 +10,29 @@ weight: 10 -애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다. -추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. +애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 +쿠버네티스를 확장할 수 있게 해준다. +추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 +미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. -애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}가 새로운 종류의 오브젝트를 인식하도록 하는 방법인 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르다. +애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}가 +새로운 종류의 오브젝트를 인식하도록 하는 방법인 +[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르다. ## 애그리게이션 레이어 -애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다. +애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, +애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 +"요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 +해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다. -APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다. extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다. apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다. +APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 *extension API server* 를 실행하는 것이다. +extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 +extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}와 쌍을 이룬다. +apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다. ### 응답 레이턴시 diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 5f7d9a072a..b1e4d2a0ae 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -17,7 +17,8 @@ weight: 10 ## 커스텀 리소스 *리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의 -[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다. +[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. +예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다. *커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시 사용할 수 있는 것은 아니다. 이는 특정 쿠버네티스 설치에 수정이 가해졌음을 나타낸다. 그러나 @@ -68,63 +69,88 @@ _선언적(declarative) API_ 를 제공하게 된다. 선언적 API에서는 다음의 특성이 있다. - - API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다. - - 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다. - - 오브젝트는 비교적 드물게 업데이트 된다. - - 사람이 종종 오브젝트를 읽고 쓸 필요가 있다. - - 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다. - - 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다. +- API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다. +- 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다. +- 오브젝트는 비교적 드물게 업데이트 된다. +- 사람이 종종 오브젝트를 읽고 쓸 필요가 있다. +- 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다. +- 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다. 명령형 API는 선언적이지 않다. 자신의 API가 선언적이지 않을 수 있다는 징후는 다음과 같다. - - 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다. - - 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다. - - RPC(원격 프로시저 호출)에 대해 얘기한다. - - 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트. - - 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다. - - 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다. - - 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다. - - API는 오브젝트로 쉽게 모델링되지 않는다. - - 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다. +- 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다. +- 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 + 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다. +- RPC(원격 프로시저 호출)에 대해 얘기한다. +- 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트. +- 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다. +- 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다. +- 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다. +- API는 오브젝트로 쉽게 모델링되지 않는다. +- 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다. ## 컨피그맵을 사용해야 하나, 커스텀 리소스를 사용해야 하나? 다음 중 하나에 해당하면 컨피그맵을 사용하자. -* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된 기존 구성 파일 형식이 있다. +* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된 + 기존 구성 파일 형식이 있다. * 전체 구성 파일을 컨피그맵의 하나의 키에 넣고 싶다. -* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여 자체 구성하는 것이다. -* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해 사용하는 것을 선호한다. +* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여 + 자체 구성하는 것이다. +* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해 + 사용하는 것을 선호한다. * 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다. {{< note >}} -민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전하다. +민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. +이는 컨피그맵과 비슷하지만 더 안전하다. {{< /note >}} 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자. * 쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다. * `kubectl` 의 최상위 지원을 원한다. 예: `kubectl get my-object object-name`. -* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다. +* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 + 구축하려고 한다. * 오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다. * `.spec`, `.status` 및 `.metadata`와 같은 쿠버네티스 API 규칙을 사용하려고 한다. -* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를 원한다. +* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를 + 원한다. ## 커스텀 리소스 추가 쿠버네티스는 클러스터에 커스텀 리소스를 추가하는 두 가지 방법을 제공한다. - CRD는 간단하며 프로그래밍 없이 만들 수 있다. -- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는 프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은 API 동작을 보다 강력하게 제어할 수 있다. +- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는 + 프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은 + API 동작을 보다 강력하게 제어할 수 있다. -쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다. +쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 +사용의 용이성이나 유연성이 저하되지 않는다. -애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다. +애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 +[API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. +사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다. -CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다. +CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API +애그리게이션을 이해할 필요는 없다. -설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며 빌트인 쿠버네티스 리소스(파드 등)와 구별된다. +설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며 +빌트인 쿠버네티스 리소스(파드 등)와 구별된다. + +{{< note >}} +커스텀 리소스를 애플리케이션, 최종 사용자, 데이터 모니터링을 위한 데이터 스토리지로 사용하는 것은 피해야 한다. +쿠버네티스 API에서 애플리케이션 데이터를 저장하는 아키텍처 구조는 +일반적으로 결합도가 너무 높기 때문이다. + +아키텍처적으로 [클라우드 네이티브](https://www.cncf.io/about/faq/#what-is-cloud-native) 애플리케이션 아키텍처들은 +컴포넌트 간 결합도를 낮추는 것을 선호한다. +워크로드 중 일부가 주기적인 작업을 위해 보조 서비스를 필요로 한다면, 해당 보조 서비스를 별도의 컴포넌트로 실행하거나 외부 서비스로 사용하자. +이를 통해 해당 워크로드는 일반적인 작업을 위해 쿠버네티스 API에 의존하지 않게 된다. +{{< /note >}} ## 커스텀리소스데피니션 @@ -145,10 +171,14 @@ CRD 오브젝트의 이름은 유효한 ## API 서버 애그리게이션 -일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다. +일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 +오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. +주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 +[CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다. -[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를 -작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다. +[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 +사용하면 자체 API 서버를 작성하고 배포하여 커스텀 리소스에 대한 +특수한 구현을 제공할 수 있다. 주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여 모든 클라이언트가 사용할 수 있게 한다. @@ -159,7 +189,8 @@ CRD는 사용하기가 더 쉽다. 애그리게이트 API가 더 유연하다. 일반적으로 CRD는 다음과 같은 경우에 적합하다. * 필드가 몇 개 되지 않는다 -* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌) 리소스를 사용하고 있다. +* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌) + 리소스를 사용하고 있다. ### 사용 편의성 비교 @@ -192,7 +223,8 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다. ### 일반적인 기능 -CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여 API에 대한 많은 기능이 제공된다. +CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여 +API에 대한 많은 기능이 제공된다. | 기능 | 설명 | | ------- | ------------ | @@ -217,40 +249,50 @@ CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플 ### 써드파티 코드 및 새로운 장애 포인트 -CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. +CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 +자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 +CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 +써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. 애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다. ### 스토리지 -커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 API 서버의 스토리지 공간이 과부하될 수 있다. +커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 +API 서버의 스토리지 공간이 과부하될 수 있다. -애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며 이 경우 동일한 경고가 적용된다. +애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며 +이 경우 동일한 경고가 적용된다. ### 인증, 권한 부여 및 감사 -CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및 감사 로깅을 사용한다. +CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및 +감사 로깅을 사용한다. -권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). 새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 타입에 대한 새로운 역할 정의와 함께 제공된다. +권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 +부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). +새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 +타입에 대한 새로운 역할 정의와 함께 제공된다. -애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나 사용하지 않을 수 있다. +애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나 +사용하지 않을 수 있다. ## 커스텀 리소스에 접근 -쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. +쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 +커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. +_Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. 커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다. - `kubectl` - 쿠버네티스 동적 클라이언트 - 작성한 REST 클라이언트 -- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다). - - +- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 + 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 + CRD 또는 AA와 함께 클라이언트를 제공할 수 있다). ## {{% heading "whatsnext" %}} - * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. - * [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. From c747a05c5a41b54bd348e8616671795616c376d0 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 25 May 2023 18:05:12 +0900 Subject: [PATCH 61/69] [ko] Resolve merge conflicts dev-1.26-ko.1 --- data/i18n/en/en.toml | 19 +--- data/i18n/ko/ko.toml | 152 ++++++++++++++++++++++++++----- layouts/shortcodes/cve-feed.html | 7 +- 3 files changed, 137 insertions(+), 41 deletions(-) diff --git a/data/i18n/en/en.toml b/data/i18n/en/en.toml index d477cb95b8..84ccb5318d 100644 --- a/data/i18n/en/en.toml +++ b/data/i18n/en/en.toml @@ -49,32 +49,17 @@ other = "CVE ID" [cve_issue_url] other = "CVE GitHub Issue URL" -[cve_json_external_url] -other = "external_url" - -[cve_json_id] -other = "id" - -[cve_json_summary] -other = "summary" - -[cve_json_url] -other = "url" - [cve_summary] other = "Issue Summary" [cve_table] other = "Official Kubernetes CVE List" -[cve_table_date_before] -other = "(last updated: " - [cve_table_date_format] other = "02 Jan 2006 15:04:05 MST" -[cve_table_date_after] -other = ")" +[cve_table_date_format_string] +other = "(last updated: %s)" [deprecation_title] other = "You are viewing documentation for Kubernetes version:" diff --git a/data/i18n/ko/ko.toml b/data/i18n/ko/ko.toml index 9ad3d0f821..6ee13452cd 100644 --- a/data/i18n/ko/ko.toml +++ b/data/i18n/ko/ko.toml @@ -1,12 +1,13 @@ # i18n strings for the Korean translation. # NOTE: Please keep the entries in alphabetical order when editing -# Avoid using conjunction_1. -# Must match the context in layouts/shortcodes/release-data.html -# Appears on https://kubernetes.io/releases/ -# For example the "and" in "Complete 1.25 Schedule and Changelog" -[conjunction_1] -other = "및" +# For "and", see [conjunction_1] + +[auto_generated_edit_notice] +other = "(자동 생성된 페이지)" + +[auto_generated_pageinfo] +other = """

    이 페이지는 자동으로 생성된 것이다.

    이 페이지에 대한 이슈를 제보할 때, 이 페이지가 자동 생성된 것임을 이슈 본문에 언급한다. 이슈에 대한 해결책은 다른 쿠버네티스 프로젝트에 적용되어야 할 수도 있다.

    """ [caution] other = "주의:" @@ -35,6 +36,12 @@ other = "Twitter" [community_youtube_name] other = "YouTube" +# Avoid using conjunction_1. +# Must match the context in layouts/shortcodes/release-data.html +# Appears on https://kubernetes.io/releases/ +# For example the "and" in "Complete 1.25 Schedule and Changelog" +[conjunction_1] +other = "및" [cve_id] other = "CVE ID" @@ -42,26 +49,17 @@ other = "CVE ID" [cve_issue_url] other = "CVE 깃헙 이슈 URL" -[cve_json_external_url] -other = "외부 URL" - -[cve_json_id] -other = "id" - -[cve_json_summary] -other = "요약" - -[cve_json_url] -other = "url" - [cve_summary] other = "이슈 요약" [cve_table] other = "공식 쿠버네티스 CVE 목록" -[cve_url] -other = "CVE URL" +[cve_table_date_format] +other = "2006년 1월 2일 15:04:05 KST" + +[cve_table_date_format_string] +other = "(최근 업데이트: %s)" [deprecation_title] other = "해당 문서의 쿠버네티스 버전:" @@ -114,14 +112,17 @@ other = "기능 상태:" [feedback_heading] other = "피드백" +[feedback_no] +other = "아니요" + [feedback_question] other = "이 페이지가 도움이 되었나요?" [feedback_yes] other = "네" -[feedback_no] -other = "아니요" +[final_patch_release] +other = "최종 패치 릴리스" [inline_list_separator] other = "," @@ -250,6 +251,9 @@ other = "옵션" [outdated_blog__message] other = "이 글은 작성일로부터 1년 이상 지났습니다. 오래된 글은 더 이상 유효하지 않은 컨텐츠를 포함하고 있을 수 있습니다. 이 페이지의 정보가 틀리지 않았는지 다시 한 번 확인하세요." +[patch_release] +other = "패치 릴리스" + [post_create_issue] other = "이슈 생성" @@ -270,18 +274,50 @@ other = "(" [release_date_format] other = "2006-01-02" +[release_cherry_pick_deadline] +other = "체리픽(Cherry Pick) 기한" + # Deprecated. Planned for removal in a future release. # Use [release_full_details_initial_text] instead. [release_complete] other = "완료" +[release_end_of_life_date] +other = "지원 종료(End Of Life) 일자" + # Replace [release_complete] with [release_full_details_initial_text] [release_full_details_initial_text] other = "전체" +[release_information_navbar] +other = "릴리스 정보" + +[release_minor_version] +other = "마이너 버전" + +[release_info_next_patch] +other = "다음 패치 릴리스는 **%s** 이다." + +# Localization note: You can use Markdown here. +# The three placeholders (in order) are: +# Kubernetes minor version +# maintenance mode date +# end of life date +# +# Keep this order. It is OK to use more than one sentence, and it's also OK to change the +# tense of the text so long as the meaning is clear. +[release_info_eol] +other = "**%s** 버전은 **%s** 에 메인터넌스 모드로 들어가며, **%s** 에 지원 종료된다." + +[release_note] +other = "정보" + [release_schedule] other = "일정" +[release_target_date] +other = "목표 일자" + [release_changelog] other = "변경 이력" @@ -327,3 +363,75 @@ other = "경고:" [whatsnext_heading] other = "다음 내용" + +[layout_docs_glossary_architecture_name] +other = "아키텍처" + +[layout_docs_glossary_architecture_description] +other = "쿠버네티스의 내부 구성요소." + +[layout_docs_glossary_community_name] +other = "커뮤니티" + +[layout_docs_glossary_community_description] +other = "쿠버네티스 오픈소스 개발 관련 사항." + +[layout_docs_glossary_core-object_name] +other = "핵심 오브젝트" + +[layout_docs_glossary_core-object_description] +other = "쿠버네티스가 기본적으로 지원하는 리소스 종류." + +[layout_docs_glossary_extension_name] +other = "확장 기능" + +[layout_docs_glossary_extension_description] +other = "쿠버네티스가 지원하는 사용자화(customization)." + +[layout_docs_glossary_fundamental_name] +other = "기본 개념" + +[layout_docs_glossary_fundamental_description] +other = "쿠버네티스를 처음 사용하는 사람을 위한 설명." + +[layout_docs_glossary_networking_name] +other = "네트워킹" + +[layout_docs_glossary_networking_description] +other = "쿠버네티스 구성요소 간, 및 클러스터 외부의 프로그램과 통신하는 방법." + +[layout_docs_glossary_operation_name] +other = "운용" + +[layout_docs_glossary_operation_description] +other = "쿠버네티스 구축 및 유지." + +[layout_docs_glossary_security_name] +other = "보안" + +[layout_docs_glossary_security_description] +other = "쿠버네티스 애플리케이션을 안전하게 보호." + +[layout_docs_glossary_storage_name] +other = "스토리지" + +[layout_docs_glossary_storage_description] +other = "쿠버네티스 애플리케이션이 영속적 자료를 다루는 방법." + +[layout_docs_glossary_tool_name] +other = "도구" + +[layout_docs_glossary_tool_description] +other = "쿠버네티스를 쉽게, 사용하기 편하게 만들어 주는 소프트웨어." + +[layout_docs_glossary_user-type_name] +other = "사용자 종류" + +[layout_docs_glossary_user-type_description] +other = "일반적인 쿠버네티스 사용자 종류." + +[layout_docs_glossary_workload_name] +other = "워크로드" + +[layout_docs_glossary_workload_description] +other = "쿠버네티스에서 실행되는 애플리케이션." diff --git a/layouts/shortcodes/cve-feed.html b/layouts/shortcodes/cve-feed.html index 7c4aa2d56c..8b829079fb 100644 --- a/layouts/shortcodes/cve-feed.html +++ b/layouts/shortcodes/cve-feed.html @@ -1,6 +1,9 @@ +{{ $feed := getJSON .Site.Params.cveFeedBucket }} +{{ if ne $feed.version "https://jsonfeed.org/version/1.1" }} + {{ warnf "CVE feed shortcode. KEP-3203: CVE feed does not comply with JSON feed v1.1." }} +{{ end }} - {{ $feed := getJSON .Site.Params.cveFeedBucket }} - + From 3fa815f76c138ded75ca92816e0ce17538bdbd0d Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Fri, 26 May 2023 13:42:25 +0900 Subject: [PATCH 62/69] [ko] Update outdated files in dev-1.26.-ko.1 [M14-17] --- .../cluster-administration/system-traces.md | 2 +- .../docs/concepts/configuration/configmap.md | 41 +------ .../manage-resources-containers.md | 8 +- .../docs/concepts/configuration/overview.md | 109 +++++++++++++----- .../ko/examples/configmap/configure-pod.yaml | 38 ++++++ 5 files changed, 129 insertions(+), 69 deletions(-) create mode 100644 content/ko/examples/configmap/configure-pod.yaml diff --git a/content/ko/docs/concepts/cluster-administration/system-traces.md b/content/ko/docs/concepts/cluster-administration/system-traces.md index e79800b127..89445ff695 100644 --- a/content/ko/docs/concepts/cluster-administration/system-traces.md +++ b/content/ko/docs/concepts/cluster-administration/system-traces.md @@ -4,7 +4,7 @@ title: 쿠버네티스 시스템 컴포넌트에 대한 추적(trace) # - logicalhan # - lilic content_type: concept -weight: 60 +weight: 90 --- diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index e8e51ca728..2e15c96a16 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -111,46 +111,7 @@ data: 다음은 `game-demo` 의 값을 사용하여 파드를 구성하는 파드 예시이다. -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: configmap-demo-pod -spec: - containers: - - name: demo - image: alpine - command: ["sleep", "3600"] - env: - # 환경 변수 정의 - - name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과 - # 대소문자가 다르다. - valueFrom: - configMapKeyRef: - name: game-demo # 이 값의 컨피그맵. - key: player_initial_lives # 가져올 키. - - name: UI_PROPERTIES_FILE_NAME - valueFrom: - configMapKeyRef: - name: game-demo - key: ui_properties_file_name - volumeMounts: - - name: config - mountPath: "/config" - readOnly: true - volumes: - # 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다. - - name: config - configMap: - # 마운트하려는 컨피그맵의 이름을 제공한다. - name: game-demo - # 컨피그맵에서 파일로 생성할 키 배열 - items: - - key: "game.properties" - path: "game.properties" - - key: "user-interface.properties" - path: "user-interface.properties" -``` +{{< codenew file="configmap/configure-pod.yaml" >}} 컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을 구분하지 않는다. diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index b4687ec73e..ea0784b76e 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -317,6 +317,10 @@ kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으 `tmpfs` emptyDir 볼륨을 추적한다. {{< /note >}} +{{< note >}} +kubelet은 임시 스토리지을 위해 오직 루트 파일시스템만을 추적한다. `/var/lib/kubelet` 혹은 `/var/lib/containers`에 대해 별도의 디스크를 마운트하는 OS 레이아웃은 임시 스토리지를 정확하게 보고하지 않을 것이다. +{{< /note >}} + ### 로컬 임시 스토리지에 대한 요청 및 제한 설정 `ephemeral-storage`를 명시하여 로컬 임시 저장소를 관리할 수 있다. @@ -343,6 +347,7 @@ Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다. 따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다. +이 제한 중 500Mi까지는 `emptyDir` 볼륨에 의해 소진될 수 있다. ```yaml apiVersion: v1 @@ -373,7 +378,8 @@ spec: mountPath: "/tmp" volumes: - name: ephemeral - emptyDir: {} + emptyDir: + sizeLimit: 500Mi ``` ### `ephemeral-storage` 요청이 있는 파드의 스케줄링 방법 diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 7852d7acff..3cd3483583 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -7,76 +7,131 @@ weight: 10 --- -이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다. - -이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다. +이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 +구성 모범 사례를 강조하고 통합한다. +이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, +새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다. ## 일반적인 구성 팁 - 구성을 정의할 때, 안정된 최신 API 버전을 명시한다. -- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 재-생성과 복원을 도와준다. +- 구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 + 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 + 재-생성과 복원을 도와준다. -- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다. +- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, + YAML이 좀 더 사용자 친화적인 성향을 가진다. -- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/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`를 호출할 수 있다. +- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, + 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다. - 불필요하게 기본 값을 명시하지 않는다. 간단하고 최소한의 설정은 에러를 덜 발생시킨다. - 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다. - ## "단독(Naked)" 파드 vs 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 그리고 잡(Job) {#naked-pods-vs-replicasets-deployments-and-jobs} -- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. - - 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다. +- 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 + [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. + 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. + 명시적으로 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)를 + 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, + ([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같이) + 파드를 교체하는 전략을 명시하는 디플로이먼트는 + 파드를 직접 생성하기 위해 항상 선호되는 방법이다. + [잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다. ## 서비스 -- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. +- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 + [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, + 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. + 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, + 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. ```shell FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> FOO_SERVICE_PORT=<서비스가 동작 중인 포트> ``` - *이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다. + *이는 순서를 정하는 일이 요구됨을 암시한다* - `파드`가 접근하기를 원하는 어떠한 `서비스`는 `파드` + 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. + DNS는 이러한 제한을 가지고 있지 않다. -- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/ko/docs/concepts/cluster-administration/addons/)은 DNS 서버이다. -DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다. +- 선택적인(그렇지만 매우 권장되는) [클러스터 애드온](/ko/docs/concepts/cluster-administration/addons/)은 + DNS 서버이다. DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. + 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, + 모든 `파드`는 `서비스`의 이름을 자동으로 해석할 수 있어야 한다. -- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다. +- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 + 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. + 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, + 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, + `protocol`의 기본 값으로 `TCP`를 사용한다. - 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. + 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, + [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) + 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. - 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스를 사용하는 것을 고려할 수 있다. + 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 + [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) + 서비스를 사용하는 것을 고려할 수 있다. - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. -- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. +- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해 + [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 + 값을 `None`으로 가지는)를 사용한다. ## 레이블 사용하기 -- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다. +- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 + 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 + [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. + 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. + 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 + 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. + 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다. -릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다. +릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 +생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다. -오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. +오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 +_적용될_ 경우, 디플로이먼트 컨트롤러는 +일정한 비율로 실제 상태를 의도한 상태로 변화시킨다. -- 일반적인 활용 사례인 경우 [쿠버네티스 공통 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)을 사용한다. 이 표준화된 레이블은 `kubectl` 및 [대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard)와 같은 도구들이 상호 운용이 가능한 방식으로 동작할 수 있도록 메타데이터를 향상시킨다. +- 일반적인 활용 사례인 경우 [쿠버네티스 공통 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)을 + 사용한다. 이 표준화된 레이블은 `kubectl` 및 + [대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard)와 + 같은 도구들이 상호 운용이 가능한 방식으로 동작할 수 있도록 메타데이터를 향상시킨다. -- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. +- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 + 셀렉터 레이블을 사용해 파드를 선택하기 때문에, + 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. + 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 + "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, + [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. ## kubectl 사용하기 -- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. +- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, + 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. -- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다. +- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. + [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 + [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 + 참고할 수 있다. -- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. +- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. + [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 + 예시를 확인할 수 있다. diff --git a/content/ko/examples/configmap/configure-pod.yaml b/content/ko/examples/configmap/configure-pod.yaml new file mode 100644 index 0000000000..67ba422662 --- /dev/null +++ b/content/ko/examples/configmap/configure-pod.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: configmap-demo-pod +spec: + containers: + - name: demo + image: alpine + command: ["sleep", "3600"] + env: + # 환경 변수 정의 + - name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과 + # 대소문자가 다르다. + valueFrom: + configMapKeyRef: + name: game-demo # 이 값의 컨피그맵. + key: player_initial_lives # 가져올 키. + - name: UI_PROPERTIES_FILE_NAME + valueFrom: + configMapKeyRef: + name: game-demo + key: ui_properties_file_name + volumeMounts: + - name: config + mountPath: "/config" + readOnly: true + volumes: + # 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다. + - name: config + configMap: + # 마운트하려는 컨피그맵의 이름을 제공한다. + name: game-demo + # 컨피그맵에서 파일로 생성할 키 배열 + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" From 4135336c73c38b2b3d4d801333a52dd321548b86 Mon Sep 17 00:00:00 2001 From: Jeong Jinwoo Date: Thu, 25 May 2023 21:19:33 +0900 Subject: [PATCH 63/69] [ko] Update outdated files in dev-1.26.-ko.1 [M18-22] --- .../ko/docs/concepts/configuration/secret.md | 162 ++++++------------ content/ko/docs/concepts/containers/_index.md | 27 ++- .../containers/container-lifecycle-hooks.md | 2 +- content/ko/docs/concepts/containers/images.md | 33 +++- .../docs/concepts/containers/runtime-class.md | 3 +- 5 files changed, 103 insertions(+), 124 deletions(-) diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 6625fe615a..05b5fd71fe 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -30,17 +30,22 @@ weight: 30 특별히 기밀 데이터를 보관하기 위한 것이다. {{< caution >}} -쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. -또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. +쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. +API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. +또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 +해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. +여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. 시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다. 1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다. -1. 시크릿 읽기 및 쓰기를 제한하는 - [RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다. - 파드 생성 권한을 가진 사람은 암묵적으로 시크릿에 접근할 수 있음에 주의한다. -1. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 - 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다. +1. 시크릿에 대한 최소한의 접근 권한을 지니도록 + [RBAC 규칙을 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/)한다. +1. 특정 컨테이너에서만 시크릿에 접근하도록 한다. +1. [외부 시크릿 저장소 제공 서비스를 사용하는 것을 고려](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)한다. + +시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인은 +[쿠버네티스 시크릿에 관한 좋은 관행](/docs/concepts/security/secrets-good-practices)를 참고한다. {{< /caution >}} @@ -96,9 +101,9 @@ weight: 30 시크릿 생성에는 다음과 같은 방법이 있다. -- [`kubectl` 명령으로 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- [환경 설정 파일을 사용하여 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- [kustomize를 사용하여 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- [`kubectl` 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [환경 설정 파일 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [kustomize 도구 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/) #### 시크릿 이름 및 데이터에 대한 제약 사항 {#restriction-names-data} @@ -125,43 +130,20 @@ weight: 30 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여 한 네임스페이스의 시크릿 (또는 다른 리소스) 수를 제한할 수 있다. -### 시크릿 편집하기 +### 시크릿 수정하기 -kubectl을 사용하여 기존 시크릿을 편집할 수 있다. +만들어진 시크릿은 [불변(immutable)](#secret-immutable)만 아니라면 수정될 수 있다. +시크릿 수정 방식은 다음과 같다. -```shell -kubectl edit secrets mysecret -``` +* [`kubectl` 사용하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret) +* [설정 파일 사용하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret) -이렇게 하면 기본으로 설정된 에디터가 열리며, -다음과 같이 `data` 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다. +[Kustomize 도구](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로 +시크릿 내부의 데이터를 수정하는 것도 가능하지만, 이 경우 수정된 데이터를 지닌 새로운 `Secret` 오브젝트가 생성된다. -```yaml -# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고, -# 빈 파일을 저장하면 편집이 취소된다. 이 파일을 저장하는 도중에 오류가 발생하면 -# 관련 오류와 함께 파일이 다시 열릴 것이다. -# -apiVersion: v1 -data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm -kind: Secret -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: { ... } - creationTimestamp: 2020-01-22T18:41:56Z - name: mysecret - namespace: default - resourceVersion: "164619" - uid: cfee02d6-c137-11e5-8d73-42010af00002 -type: Opaque -``` - -위의 예시 매니페스트는 `data`에 `username` 및 `password` 2개의 키를 갖는 시크릿을 정의한다. -매니페스트에서 이 값들은 Base64 문자열이지만, -이 시크릿을 파드에 대해 사용할 때에는 kubelet이 파드와 컨테이너에 _디코드된_ 데이터를 제공한다. - -한 시크릿에 여러 키 및 값을 넣을 수도 있고, 여러 시크릿으로 정의할 수도 있으며, 둘 중 편리한 쪽을 고르면 된다. +시크릿을 생성한 방법이나 파드에서 시크릿이 어떻게 사용되는지에 따라, +존재하는 `Secret` 오브젝트에 대한 수정은 해당 데이터를 사용하는 파드들에 자동으로 전파된다. +자세한 정보는 [마운트된 시크릿의 자동 업데이트](#마운트된-시크릿의-자동-업데이트)를 참고하라. ### 시크릿 사용하기 @@ -202,9 +184,14 @@ kubelet은 또한 시크릿을 가져올 수 없는 문제에 대한 세부 정 이렇게 구성하려면, 다음을 수행한다. 1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다. -1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다. -1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 `.spec.containers[].volumeMounts[].readOnly = true` 와 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. -1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 각 키는 `mountPath` 아래의 파일명이 된다. +1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, + 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다. +1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. + 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 + `.spec.containers[].volumeMounts[].readOnly = true`와 + `.spec.containers[].volumeMounts[].mountPath`를 지정한다. +1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 + 각 키는 `mountPath` 아래의 파일명이 된다. 다음은 볼륨에 `mysecret`이라는 시크릿을 마운트하는 파드의 예시이다. @@ -320,11 +307,10 @@ spec: 시크릿이 `/etc/foo` 에 마운트되고, 시크릿 볼륨 마운트로 생성된 모든 파일의 퍼미션은 `0400` 이다. - {{< note >}} -JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우, -JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다. -`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다). +JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우, +JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다. +`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다). YAML로 작성하는 경우, `defaultMode` 값을 8진수로 표기할 수 있다. {{< /note >}} @@ -369,7 +355,7 @@ cat /etc/foo/password 컨테이너의 프로그램은 필요에 따라 이러한 파일에서 시크릿 데이터를 읽는다. -#### 마운트된 시크릿은 자동으로 업데이트됨 +#### 마운트된 시크릿의 자동 업데이트 볼륨이 시크릿의 데이터를 포함하고 있는 상태에서 시크릿이 업데이트되면, 쿠버네티스는 이를 추적하고 최종적으로 일관된(eventually-consistent) 접근 방식을 사용하여 볼륨 안의 데이터를 업데이트한다. @@ -1186,7 +1172,7 @@ data: - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. -- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 +- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339)를 사용하는 절대 UTC 시간. 선택 사항. - `usage-bootstrap-`: 부트스트랩 토큰의 추가적인 사용처를 나타내는 불리언(boolean) 플래그. @@ -1218,22 +1204,23 @@ stringData: ``` -## 수정 불가능한(immutable) 시크릿 {#secret-immutable} +## 불변(immutable) 시크릿 {#secret-immutable} {{< feature-state for_k8s_version="v1.21" state="stable" >}} -쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _수정 불가능_ 으로 표시할 수 있다. +쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _불변_ 으로 표시할 수 있다. 기존 시크릿 데이터의 변경을 금지시키면 다음과 같은 이점을 가진다. - 잘못된(또는 원치 않은) 업데이트를 차단하여 애플리케이션 중단을 방지 - (수만 개 이상의 시크릿-파드 마운트와 같이 시크릿을 대규모로 사용하는 클러스터의 경우,) - 수정 불가능한 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다. - kubelet은 수정 불가능으로 지정된 시크릿에 대해서는 + 불변 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다. + kubelet은 불변으로 지정된 시크릿에 대해서는 [감시(watch)]를 유지할 필요가 없기 때문이다. -### 시크릿을 수정 불가능으로 지정하기 {#secret-immutable-create} +### 시크릿을 불변으로 지정하기 {#secret-immutable-create} + +다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 불변 시크릿을 만들 수 있다. -다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 수정 불가능한 시크릿을 만들 수 있다. ```yaml apiVersion: v1 kind: Secret @@ -1244,10 +1231,10 @@ data: immutable: true ``` -또한 기존의 수정 가능한 시크릿을 변경하여 수정 불가능한 시크릿으로 바꿀 수도 있다. +또한 기존의 수정 가능한 시크릿을 변경하여 불변 시크릿으로 바꿀 수도 있다. {{< note >}} -시크릿 또는 컨피그맵이 수정 불가능으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_. +시크릿 또는 컨피그맵이 불변으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_. 시크릿을 삭제하고 다시 만드는 것만 가능하다. 기존의 파드는 삭제된 시크릿으로의 마운트 포인트를 유지하기 때문에, 이러한 파드는 재생성하는 것을 추천한다. @@ -1280,61 +1267,14 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한 따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다. {{< warning >}} -노드 상의 높은 권한을 갖는(privileged) 컨테이너는 -해당 노드에 있는 모든 시크릿에 접근할 수 있다. +특정 노드에 대해 `privileged: true`가 설정되어 실행 중인 컨테이너들은 전부 +해당 노드에서 사용 중인 모든 시크릿에 접근할 수 있다. {{< /warning >}} - -### 개발자를 위한 보안 추천 사항 - -- 애플리케이션은 환경 변수 또는 볼륨에서 기밀 정보를 읽은 뒤에 기밀 정보를 계속 보호해야 한다. - 예를 들어, 애플리케이션은 비밀 데이터를 암호화되지 않은 상태로 기록하거나 - 신뢰할 수 없는 당사자에게 전송하지 말아야 한다. -- 파드에 여러 컨테이너가 있고, - 그 중 한 컨테이너만 시크릿에 접근해야 하는 경우, - 다른 컨테이너는 해당 시크릿에 접근할 수 없도록 - 볼륨 마운트 또는 환경 변수 구성을 적절히 정의한다. -- {{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 통해 시크릿을 구성하고, - 이 안에 비밀 데이터가 base64로 인코딩된 경우, - 이 파일을 공유하거나 소스 저장소에 올리면 - 해당 매니페스트를 읽을 수 있는 모든 사람이 이 비밀 정보를 볼 수 있음에 주의한다. - base64 인코딩은 암호화 수단이 _아니기 때문에_, 평문과 마찬가지로 기밀성을 제공하지 않는다. -- 시크릿 API와 통신하는 애플리케이션을 배포할 때, - [RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 - [인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여 - 접근을 제한해야 한다. -- 쿠버네티스 API에서, 네임스페이스 내 시크릿에 대한 `watch` 와 `list` 요청은 매우 강력한 기능이다. - 시크릿 목록 조회를 가능하게 하면 - 클라이언트가 해당 네임스페이스에 있는 모든 시크릿의 값을 검사할 수도 있기 때문에 - 가능한 한 이러한 접근 권한을 주는 것은 피해야 한다. - -### 클러스터 관리자를 위한 보안 추천 사항 - -{{< caution >}} -시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값을 볼 수도 있다. -클러스터 정책에서 사용자가 직접 시크릿을 조회하는 것을 금지했더라도, -동일한 사용자가 시크릿을 노출하는 파드에 접근 권한을 가질 수 있다. -{{< /caution >}} - -- (쿠버네티스 API를 사용하여) 클러스터의 모든 시크릿을 감시(`watch`) 또는 나열(`list`)하는 권한을 제한하여, - 가장 특권이 있는 시스템 레벨의 컴포넌트에만 이 동작을 허용한다. -- 시크릿 API와 통신하는 애플리케이션을 배포할 때, - [RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 - [인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여 - 접근을 제한해야 한다. -- API 서버에서, (시크릿을 포함한) 오브젝트는 - {{< glossary_tooltip term_id="etcd" >}}에 저장된다. 그러므로 - - 클러스터 관리자만 etcd에 접근할 수 있도록 한다(읽기 전용 접근 포함) - - 시크릿 오브젝트에 대해 - [저장된 데이터 암호화(encryption at rest)](/docs/tasks/administer-cluster/encrypt-data/)를 활성화하여, - 이러한 시크릿의 데이터가 {{< glossary_tooltip term_id="etcd" >}}에 암호화되지 않은 상태로 저장되지 않도록 한다. - - etcd가 동작하던 장기 저장 장치를 더 이상 사용하지 않는다면 - 초기화 또는 파쇄하는 것을 검토한다. - - etcd 인스턴스가 여러 개라면, - etcd 피어 간 통신에 SSL/TLS를 사용하고 있는지 확인한다. - ## {{% heading "whatsnext" %}} +- 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인을 원한다면 + [쿠버네티스 시크릿을 다루는 좋은 관행들](/docs/concepts/security/secrets-good-practices)을 참고하라. - [`kubectl` 을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [구성 파일을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [kustomize를 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md index 5d35733a95..9f86172de4 100644 --- a/content/ko/docs/concepts/containers/_index.md +++ b/content/ko/docs/concepts/containers/_index.md @@ -6,7 +6,6 @@ description: 런타임 의존성과 함께 애플리케이션을 패키징하는 # - erictune # - thockin content_type: concept -no_list: true --- @@ -18,7 +17,10 @@ no_list: true 컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다. 따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다. - +쿠버네티스 클러스터에 있는 개별 {{< glossary_tooltip text="node" term_id="node" >}}는 +해당 노드에 할당된 [파드](/docs/concepts/workloads/pods/)를 +구성하는 컨테이너들을 실행한다. +파드 내부에 컨테이너들은 같은 노드에서 실행될 수 있도록 같은 곳에 위치하고 함께 스케줄된다. @@ -29,16 +31,23 @@ no_list: true 여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, 그리고 모든 필수 설정에 대한 기본값이 포함된다. -설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를 -변경할 수 없다. 컨테이너화된 애플리케이션이 있고 -변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한 -다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다. +컨테이너는 스테이트리스하며 +[불변(immutable)](https://glossary.cncf.io/immutable-infrastructure/)일 것으로 계획되었다. +즉, 이미 실행 중인 컨테이너의 코드를 수정해서는 안된다. +만일 컨테이너화된 애플리케이션에 수정을 가하고 싶다면, +수정 내역을 포함한 새로운 이미지를 빌드하고, +업데이트된 이미지로부터 +컨테이너를 새로 생성하는 것이 올바른 방법이다. ## 컨테이너 런타임 {{< glossary_definition term_id="container-runtime" length="all" >}} -## {{% heading "whatsnext" %}} +일반적으로 클러스터에서 파드의 기본 컨테이너 런타임을 선택하도록 허용할 수 있다. +만일 클러스터에서 복수의 컨테이너 런타임을 사용해야 하는 경우, +파드에 대해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)을 명시함으로써 +쿠버네티스가 특정 컨테이너 런타임으로 +해당 컨테이너들을 실행하도록 설정할 수 있다. -* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 -* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 +또한 런타임클래스을 사용하면 하나의 컨테이너 런타임을 사용하여 복수의 파드들을 +각자 다른 설정으로 실행할 수도 있다. diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index 21d5b3327f..85521e32cb 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -4,7 +4,7 @@ # - thockin title: 컨테이너 라이프사이클 훅(Hook) content_type: concept -weight: 30 +weight: 40 --- diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 5ad0fa4ec6..95f9a28e58 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -5,6 +5,7 @@ title: 이미지 content_type: concept weight: 10 +hide_summary: true # 섹션의 목차에 별도로 기재 --- @@ -19,6 +20,12 @@ weight: 10 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. +{{< note >}} +(v{{< skew latestVersion >}}와 같은 최신 마이너 릴리즈와 같은) +쿠버네티스 릴리즈에 대한 컨테이너 이미지를 찾고 있다면 +[쿠버네티스 다운로드](https://kubernetes.io/releases/download/)를 확인하라. +{{< /note >}} + ## 이미지 이름 @@ -149,9 +156,16 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 ## 이미지 인덱스가 있는 다중 아키텍처 이미지 -바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 +[컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 +제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 +[이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. +아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. +그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. -쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. +쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, +접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 +또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. ## 프라이빗 레지스트리 사용 @@ -160,6 +174,9 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 + - Kubelet 자격증명 제공자(Credential Provider)를 통해 프라이빗 레지스트리로부터 동적으로 자격증명을 가져오기 + - kubelet은 특정 프라이빗 레지스트리에 대해 자격증명 제공자 실행 + 플러그인(credential provider exec plugin)을 사용하도록 설정될 수 있다. - 미리 내려받은(pre-pulled) 이미지 - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 @@ -180,6 +197,18 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 [프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다. 해당 예시는 도커 허브에서 제공하는 프라이빗 레지스트리를 사용한다. +### 인증된 이미지를 가져오기 위한 Kubelet 자격증명 제공자(Credential Provider) {#kubelet-credential-provider} + +{{< note >}} +해당 방식은 kubelet이 자격증명을 동적으로 가져와야 할 때 특히 적절하다. +가장 일반적으로 클라우드 제공자로부터 제공받은 레지스트리에 대해 사용된다. 인증 토큰의 수명이 짧기 때문이다. +{{< /note >}} + +kubelet에서 플러그인 바이너리를 호출하여 컨테이너 이미지에 대한 레지스트리 자격증명을 동적으로 가져오도록 설정할 수 있다. +이는 프라이빗 레지스트리에서 자격증명을 가져오는 방법 중 가장 강력하며 휘발성이 있는 방식이지만, 활성화하기 위해 kubelet 수준의 구성이 필요하다. + +자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다. + ### config.json 파일 해석 {#config-json} `config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 28a1e10fe7..81c26e133c 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -4,7 +4,8 @@ # - dchen1107 title: 런타임클래스(RuntimeClass) content_type: concept -weight: 20 +weight: 30 +hide_summary: true # 섹션의 목차에 별도로 기재 --- From fcb37c4c85bf847df27aa7cb4e26d6e4fb0ed551 Mon Sep 17 00:00:00 2001 From: namuk2004 Date: Sun, 14 May 2023 11:34:07 +0900 Subject: [PATCH 64/69] Translate reference/node/kubelet-checkpoint-api in Korean Translate reference/node/kubelet-checkpoint-api in Korean Translate reference/node/kubelet-checkpoint-api in Korean Translate reference/node/kubelet-checkpoint-api in Korean --- .../reference/node/kubelet-checkpoint-api.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 content/ko/docs/reference/node/kubelet-checkpoint-api.md diff --git a/content/ko/docs/reference/node/kubelet-checkpoint-api.md b/content/ko/docs/reference/node/kubelet-checkpoint-api.md new file mode 100644 index 0000000000..1c8a057418 --- /dev/null +++ b/content/ko/docs/reference/node/kubelet-checkpoint-api.md @@ -0,0 +1,96 @@ +--- +content_type: reference +title: kubelet 체크포인트 API +weight: 10 +--- + + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +컨테이너 체크포인트는 실행 중인 컨테이너의 스테이트풀(stateful) 복사본을 생성하는 기능이다. +컨테이너의 스테이트풀 복사본이 있으면, +디버깅 또는 다른 목적을 위해 이를 다른 컴퓨터로 이동할 수 있다. + +체크포인트 컨테이너 데이터를 복원할 수 있는 컴퓨터로 이동하면, +복원된 컨테이너는 체크포인트된 지점과 +정확히 동일한 지점에서 계속 실행된다. 적절한 도구가 있다면, +저장된 데이터를 검사해 볼 수도 있다. + +컨테이너 체크포인트 생성 시에는 유의해야 할 보안 사항이 있다. +일반적으로 각 체크포인트는 체크포인트된 컨테이너의 모든 프로세스의 메모리 페이지를 포함한다. +이는 곧 메모리에 있던 모든 데이터가 로컬 디스크에 저장되어 열람이 가능함을 의미한다. +이 아카이브(archive)에는 모든 개인 데이터와 암호화 키가 포함된다. +따라서, 내부 CRI 구현체(노드의 컨테이너 런타임)는 +체크포인트 아카이브를 생성 시 `root` 사용자만 액세스 가능하도록 처리해야 한다. +그럼에도 여전히 주의가 필요한데, 체크포인트 아카이브를 다른 시스템으로 전송하게 되면 해당 시스템의 체크포인트 아카이브 소유자가 +모든 메모리 페이지를 읽을 수 있기 때문이다. + +## 운영 {#operations} + +### `POST` 특정 컨테이너의 체크포인트 생성 {#post-checkpoint} + +지정된 파드의 특정 컨테이너를 체크포인트하도록 kubelet에 지시한다. + +kubelet 체크포인트 인터페이스로의 접근이 어떻게 제어되는지에 대한 자세한 내용은 +[Kubelet 인증/인가 레퍼런스](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/) +를 참고한다. + +kubelet은 내부 {{}} 구현체에 +체크포인트를 요청한다. +체크포인트 요청 시, kubelet은 체크포인트 아카이브의 이름을 +`checkpoint---.tar`로 지정하고 +루트 디렉토리(`--root-dir` 로 지정 가능) 아래의 `checkpoints` 디렉토리에 +체크포인트 아카이브를 저장하도록 요청한다. +기본값은 `/var/lib/kubelet/checkpoints`이다. + +체크포인트 아카이브는 _tar_ 형식이며 +[`tar`](https://pubs.opengroup.org/onlinepubs/7908799/xcu/tar.html) 유틸리티를 사용하여 조회해 볼 수 있다. +아카이브의 내용은 내부 CRI 구현체(노드의 컨테이너 런타임)에 따라 다르다. + +#### HTTP 요청 {#post-checkpoint-request} + +POST /checkpoint/{namespace}/{pod}/{container} + +#### 파라미터 {#post-checkpoint-params} + +- **namespace** (*경로 내 파라미터*): 문자열(string), 필수 + + {{< glossary_tooltip term_id="namespace" >}} + +- **pod** (*경로 내 파라미터*): 문자열(string), 필수 + + {{< glossary_tooltip term_id="pod" >}} + +- **container** (*경로 내 파라미터*): 문자열(string), 필수 + + {{< glossary_tooltip term_id="container" >}} + +- **timeout** (*쿼리 파라미터*): 정수(integer) + + 체크포인트 생성이 완료될 때까지 대기할 시간제한(초)이다. + 시간 제한이 0 또는 지정되지 않은 경우 + 기본 {{}} 시간 제한 값이 사용될 것이다. + 체크포인트 생성 시간은 컨테이너가 사용하고 있는 메모리에 따라 다르다. + 컨테이너가 사용하는 메모리가 많을수록 해당 체크포인트를 생성하는 데 + 더 많은 시간이 필요하다. + +#### 응답 {#post-checkpoint-response} + +200: OK + +401: Unauthorized + +404: Not Found (`ContainerCheckpoint` 기능 게이트가 비활성화된 경우) + +404: Not Found (명시한 `namespace`, `pod` 또는 `container`를 찾을 수 없는 경우) + +500: Internal Server Error (CRI 구현체가 체크포인트를 수행하는 중에 오류가 발생한 경우 (자세한 내용은 오류 메시지를 확인한다.)) + +500: Internal Server Error (CRI 구현체가 체크포인트 CRI API를 구현하지 않은 경우 (자세한 내용은 오류 메시지를 확인한다.)) + +{{< comment >}} +TODO: CRI 구현체가 체크포인트/복원 기능을 가지게 되면 반환 코드에 대한 자세한 정보를 추가해야 한다. + CRI 구현체는 새로운 ContainerCheckpoint CRI API 호출을 구현하기 위한 + 쿠버네티스의 변경이 필요하기 때문에 릴리스 전에는 TODO를 수정할 수 없다. + 이 문제를 해결하려면 1.25 릴리스 이후를 기다려야 한다. +{{< /comment >}} \ No newline at end of file From 6d160611e6f27f296444f5259d476e1e7f932e64 Mon Sep 17 00:00:00 2001 From: Jongmin Han / Jeff <39541657+dewble@users.noreply.github.com> Date: Sat, 15 Apr 2023 01:12:14 +0900 Subject: [PATCH 65/69] Delete kubelet-config-file.md --- .../kubeadm/upgrading-linux-nodes.md | 18 ++--- .../administer-cluster/kubelet-config-file.md | 74 ------------------- 2 files changed, 9 insertions(+), 83 deletions(-) delete mode 100644 content/ko/docs/tasks/administer-cluster/kubelet-config-file.md diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md index 33c4c017db..258ff29c13 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes.md @@ -21,12 +21,12 @@ weight: 100 ### kubeadm 업그레이드 - kubeadm 업그레이드. + kubeadm을 업그레이드한다. {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} ```shell - # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + # {{< skew currentVersion >}}.x-00 에서 x 에 최신 버전을 넣는다. apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm @@ -34,7 +34,7 @@ weight: 100 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} ```shell - # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + # {{< skew currentVersion >}}.x-00 에서 x 에 최신 버전을 넣는다. yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes ``` {{% /tab %}} @@ -53,7 +53,7 @@ weight: 100 - 노드를 스케줄 불가능한 것으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. ```shell - # replace with the name of your node you are draining + # 에 드레인하려는 노드의 이름을 넣는다. kubectl drain --ignore-daemonsets ``` @@ -64,7 +64,7 @@ weight: 100 {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} ```shell - # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + # {{< skew currentVersion >}}.x-00 에서 x 에 최신 버전을 넣는다. apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl @@ -72,14 +72,14 @@ weight: 100 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} ```shell - # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + # {{< skew currentVersion >}}.x-00 에서 x 에 최신 버전을 넣는다. yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes ``` {{% /tab %}} {{< /tabs >}}
    -- kubelet 재시작 +- kubelet을 재시작한다. ```shell sudo systemctl daemon-reload @@ -91,10 +91,10 @@ weight: 100 - 스케줄 가능으로 표시하여 노드를 다시 온라인으로 가져온다. ```shell - # replace with the name of your node + # 에 노드의 이름을 넣는다. kubectl uncordon ``` ## {{% heading "whatsnext" %}} -* [윈도우 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes/)하는 방법. \ No newline at end of file +* [윈도우 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes/)하는 방법을 알아본다. \ No newline at end of file diff --git a/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md b/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md deleted file mode 100644 index e1b0581496..0000000000 --- a/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -reviewers: -# - mtaufen -# - dawnchen -title: 구성 파일을 통해 Kubelet 파라미터 설정하기 -content_type: task ---- - - - -커맨드 라인 플래그 대신 온디스크 구성 파일을 통해 -Kubelet의 구성 매개변수 하위 집합을 설정할 수 있다. - -구성 파일을 통해 매개변수를 제공하는 것은 -노드 배포 및 구성 관리를 간소화하기 때문에 권장되는 접근 방식이다. - - - -## 구성 파일 만들기 - -파일을 통해 구성할 수 있는 -Kubelet 구성의 하위 집합은 -[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) -에 의해 정의된다. - -구성 파일은 이 구조체의 매개 변수를 반드시 JSON 또는 YAML로 표현한 파일이어야 한다. -Kubelet에 파일에 읽기 권한이 있는지 확인한다. - -다음은 이 파일의 모습에 대한 예입니다. -``` -apiVersion: kubelet.config.k8s.io/v1beta1 -kind: KubeletConfiguration -address: "192.168.0.8", -port: 20250, -serializeImagePulls: false, -evictionHard: - memory.available: "200Mi" -``` - -이 예제에서, Kubelet은 IP 주소 192.168.0.8과 20250 포트에서 동작하고, 이미지를 병렬로 가져오고, -사용 가능 메모리가 200Mi 아래로 떨어지면 파드를 축출하도록 구성되어 있다. -플래그에 의해 재정의되지 않는한, 다른 모든 Kubelet 구성은 기본값으로 유지된다. -구성 파일과 동일한 값을 대상으로 하는 커맨드 라인 플래그는 해당 값을 재정의 한다. - -## 구성 파일을 통해 구성된 Kubelet 프로세스 시작하기 - -{{< note >}} -kubeadm을 사용하여 클러스터를 초기화하는 경우 `kubeadmin init`으로 클러스터를 생성하는 동안 kubelete-config를 사용해야 한다. -자세한 내용은 [kubeadm을 사용하여 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/)를 참고한다. -{{< /note >}} - -Kubelet의 구성 파일 경로로 설정된 `--config` 플래그를 사용하여 Kubelet을 시작하면 -Kubelet이 이 파일에서 구성을 불러온다. - -구성 파일과 동일한 값을 대상으로 하는 커맨드 라인 플래그는 해당 값을 재정의한다는 점을 유의한다. -이렇게 하면 커맨드 라인 API와의 이전 버전과의 호환성을 보장할 수 있다. - -Kubelet 구성 파일의 상대 파일 경로는 -Kubelet 구성 파일의 위치를 기준으로 확인되는 반면, 커맨드 라인 플래그의 상대 경로는 -Kubelet의 현재 작업 디렉터리를 기준으로 확인된다는 점에 유의한다. - -일부 기본값은 커맨드 라인 플래그와 Kubelet 구성 파일 간에 다르다는 점에 유의한다. -`--config`가 제공되고 명령줄을 통해 값을 지정하지 않은 경우, -`KubeletConfiguration` 버전의 기본값이 적용된다. -위 예제의 버전은 `kubelet.config.k8s.io/v1beta1`이다. - - - -## {{% heading "whatsnext" %}} - -- Kubelet 구성에 대한 자세한 내용은 - [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) - 를 참고한다. - From cfb55db9cfeb2cd04f0fd7f394865323fe590560 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Wed, 22 Feb 2023 14:47:57 +0900 Subject: [PATCH 66/69] [ko] Update outdated files in dev-1.26-ko.1 (M109-M110) --- .../service-accounts-admin.md | 422 ++++++++++++++---- .../command-line-tools-reference/_index.md | 2 +- .../secret/serviceaccount/mysecretname.yaml | 7 + 3 files changed, 338 insertions(+), 93 deletions(-) create mode 100644 content/ko/examples/secret/serviceaccount/mysecretname.yaml 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 85df22f037..d6cd18c4bc 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 @@ -11,110 +11,147 @@ weight: 50 -이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다. -독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다. +_서비스어카운트(ServiceAccount)_ 는 파드에서 실행되는 프로세스에 대한 식별자를 제공한다. -인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다. -서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다. +파드 내부의 프로세스는, 자신에게 부여된 서비스 어카운트의 식별자를 사용하여 +클러스터의 API 서버에 인증할 수 있다. + +서비스 어카운트에 대한 소개는, [서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)를 참고한다. + +이 가이드는 서비스어카운트와 관련된 개념 중 일부를 설명하며, +서비스어카운트를 나타내는 토큰을 얻거나 취소하는 +방법에 대해서도 설명한다. +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +아래 내용들을 따라하기 위해서는 +`examplens`라는 네임스페이스가 필요하다. +없을 경우 다음과 같이 네임스페이스를 생성한다. + +```shell +kubectl create namespace examplens +``` + ## 사용자 어카운트와 서비스 어카운트 비교 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다. -- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 - 위한 것이다. -- 사용자 어카운트는 전역을 대상으로 고려된다. - 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다. +- 사용자 어카운트는 사람을 위한 것이지만, 서비스 어카운트는 쿠버네티스의 경우 파드의 일부 컨테이너에서 실행되는 + 애플리케이션 프로세스를 위한 것이다. +- 사용자 어카운트는 전역적으로 고려되기 때문에, + 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 어떤 네임스페이스를 확인하든지 간에, + 특정 사용자명은 해당 유저만을 나타낸다. + 쿠버네티스에서 서비스 어카운트는 네임스페이스별로 구분된다. 두 개의 서로 다른 네임스페이스는 + 동일한 이름의 서비스어카운트를 각자 가질 수 있다. - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. - 서비스 어카운트 생성은 + 반면에 서비스 어카운트를 생성하는 경우는, 클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 보다 가볍게 만들어졌다. -- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다. + 실 사용자를 온보딩하는 단계와 서비스어카운트를 생성하는 단계를 분리하는 것은, + 워크로드가 최소 권한 원칙을 따르기 쉬워지게 한다. +- 사람과 서비스 어카운트에 대한 감사 고려 사항은 다를 수 있다. 이 둘을 따로 관리함으로써 + 더욱 쉽게 감사를 수행할 수 있다. - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. - 서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에 + 서비스 어카운트는 많은 제약없이 만들 수 있고 + 네임스페이스에 할당된 이름을 가질 수 있기 때문에 이러한 설정은 이식성이 좋다. -## 서비스 어카운트 자동화 - -서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다. - -- `ServiceAccount` 어드미션 컨트롤러 -- 토큰 컨트롤러 -- `ServiceAccount` 컨트롤러 - -### 서비스어카운트(ServiceAccount) 어드미션 컨트롤러 - -파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는 -플러그인을 통해 구현된다. -이것은 API 서버의 일부이다. -파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다. -이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다. - -1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다. -1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다. -1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 - 어느 것도 `false` 로 설정되어 있지 않다면, - API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다. -1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, - `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 - `volumeSource` 를 추가한다. -1. 파드에 `imagePullSecrets` 이 없는 경우, - `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다. - -#### 바인딩된 서비스 어카운트 토큰 볼륨 +## 바인딩된 서비스 어카운트 토큰 볼륨 메커니즘 {#bound-service-account-token-volume} {{< feature-state for_k8s_version="v1.22" state="stable" >}} -서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 -시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. +기본적으로, +쿠버네티스 컨트롤 플레인(구체적으로 말하자면 [서비스어카운트 어드미션 컨트롤러](#service-account-admission-controller))은 +[프로젝티드 볼륨](/ko/docs/concepts/storage/projected-volumes/)을 파드에 추가하며, +이 볼륨은 쿠버네티스 API에 접근할 수 있는 토큰을 포함한다. + +다음은 실행된 파드에서 해당 토큰이 어떻게 보이는지에 대한 예시이다. ```yaml -- name: kube-api-access- - projected: - defaultMode: 420 # 0644 - sources: - - serviceAccountToken: - expirationSeconds: 3607 - path: token - - configMap: - items: - - key: ca.crt - path: ca.crt - name: kube-root-ca.crt - - downwardAPI: - items: - - fieldRef: - apiVersion: v1 - fieldPath: metadata.namespace - path: namespace +... + - name: kube-api-access- + projected: + sources: + - serviceAccountToken: + path: token # 애플리케이션이 알고 있는 경로와 일치해야 한다. + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace ``` -프로젝티드 볼륨은 세 가지로 구성된다. +위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. +이 경우, 각 정보는 해당 볼륨 내의 단일 경로를 나타내기도 한다. 세 가지 정보는 다음과 같다. -1. `kube-apiserver`로부터 TokenRequest API를 통해 얻은 `서비스어카운트토큰(ServiceAccountToken)`. - 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. - 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다. -1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 `컨피그맵(ConfigMap)`. -1. 파드의 네임스페이스를 참조하는 `DownwardAPI`. +1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. + kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. + 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). + 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. + 이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. + 해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 토큰과는 달리 만료가 되지 않는 것이었다. +1. `컨피그맵(ConfigMap)` 정보는 인증 및 인가에 관한 번들을 포함한다. + 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) + 에 대한 연결을 확인할 수 있다. +1. `DownwardAPI` 정보는 파드가 포함된 네임스페이스를 검색하고, + 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다. -상세 사항은 [프로젝티드 볼륨](/ko/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. +이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다. + +{{< note >}} +TokenRequest를 통해 발급된 토큰을 무효화하는 메커니즘은 없다. +만약 파드에 바인딩된 서비스 어카운트 토큰을 더 이상 신뢰하지 못하게 된다면, 파드를 삭제한다. +파드를 삭제하면 바인딩 되어있던 서비스 어카운트 토큰 역시 만료된다. +{{< /note >}} + +## 서비스어카운트에 대해 수동으로 시크릿 관리하기 + +쿠버네티스 v1.22 이전의 버전들은 쿠버네티스 API에 접근하기 위한 자격 증명들을 자동으로 생성했다. +이러한 옛 메커니즘들은, 실행 중인 파드에 마운트 될 수 있는 +토큰 시크릿을 만드는 것에 기반을 두었다. + +쿠버네티스 v{{< skew currentVersion >}}을 포함한 최신 버전에서는, +API 자격 증명들은 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 사용하여 +[직접 얻을 수 있으며](#bound-service-account-token-volume), +프로젝티드 볼륨을 사용하여 파드에 마운트할 수 있다. +이 방법으로 취득한 토큰은 시간 제한이 있으며, +마운트 되었던 파드가 삭제되는 경우 자동으로 만료된다. + +예를 들어 평생 만료되지 않는 토큰이 필요한 경우, 서비스 어카운트 토큰을 유지하기 위한 시크릿을 [수동으로 생성](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)할 수 있다. + +한 번 시크릿을 수동으로 생성하여 서비스어카운트에 연결했다면, 쿠버네티스 컨트롤 플레인은 자동으로 해당 시크릿에 토큰을 채운다. + +{{< note >}} +장기간 사용할 서비스어카운트 토큰을 수동으로 생성하는 메커니즘이 존재하지만, +단기간 동안에만 사용할 토큰을 취득하는 경우 +[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)를 사용하는 것이 권장된다. +{{< /note >}} + +## 컨트롤 플레인의 세부 사항들 ### 토큰 컨트롤러 -토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는, +토큰 컨트롤러는 `kube-controller-manager` 의 일부로써 실행되며, +비동기적으로 동작한다. -- 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당 - 서비스어카운트 토큰 시크릿을 생성한다. -- 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트 - 토큰 시크릿을 삭제한다. -- 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가 - 존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다. -- 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서 - 참조를 제거한다. +- 서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 + 토큰 시크릿을 같이 삭제한다. +- 서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 + 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다. +- 시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 + 참조 중인 항목들을 제거한다. 서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 @@ -123,39 +160,240 @@ weight: 50 `kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다. -#### 추가적인 API 토큰 생성 +### 서비스어카운트 어드미션 컨트롤러 -컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다. -서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해 -서비스어카운트를 참조하는 어노테이션과 함께 -`kubernetes.io/service-account-token` 유형의 시크릿을 생성하면 -컨트롤러가 새로 생성된 토큰으로 갱신한다. +파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는 +플러그인을 통해 구현된다. +이것은 API 서버의 일부이며, +파드가 생성될 때 파드를 수정하기 위해 동기적으로 동작한다. +이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우, +어드미션 컨트롤러는 파드의 생성 시점에 다음 작업들을 수행한다. -다음은 시크릿에 대한 샘플 구성이다. +1. 파드에 `.spce.serviceAccountName` 항목이 지정되지 않았다면, 어드미션 컨트롤러는 + 실행하려는 파드의 서비스어카운트 이름을 `default`로 설정한다. +1. 어드미션 컨트롤러는 실행되는 파드가 참조하는 서비스어카운트가 존재하는지 확인한다. + 만약 해당하는 이름의 서비스어카운트가 존재하지 않는 경우, 어드미션 컨트롤러는 파드를 실행시키지 않는다. + 이는 `default` 서비스어카운트에 대해서도 동일하게 적용된다. +1. 서비스어카운트의 `automountServiceAccountToken` 또는 파드의 `automountServiceAccountToken` 중 + 어느 것도 `false` 로 설정되어 있지 않다면, + - 어드미션 컨트롤러는 실행하려는 파드에 + API에 접근할 수 있는 토큰을 포함하는 + {{< glossary_tooltip text="볼륨" term_id="volume" >}} 을 추가한다. + - 어드미션 컨트롤러는 파드의 각 컨테이너에 `volumeMount`를 추가한다. + 이미 `/var/run/secrets/kubernetes.io/serviceaccount` 경로에 볼륨이 마운트 되어있는 + 컨테이너에 대해서는 추가하지 않는다. + 리눅스 컨테이너의 경우, 해당 볼륨은 `/var/run/secrets/kubernetes.io/serviceaccount` 위치에 마운트되며, + 윈도우 노드 역시 동일한 경로에 마운트된다. +1. 파드의 spec에 `imagePullSecrets` 이 없는 경우, + 어드미션 컨트롤러는 `ServiceAccount`의 `imagePullSecrets`을 복사하여 추가된다. + +### TokenRequest API + +{{< feature-state for_k8s_version="v1.22" state="stable" >}} + +서비스어카운트의 하위 리소스인 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)를 사용하여 +일정 시간 동안 해당 서비스어카운트에서 사용할 수 있는 토큰을 가져올 수 있다. +컨테이너 내에서 사용하기 위한 API 토큰을 얻기 위해 이 요청을 직접 호출할 필요는 없는데, +kubelet이 _프로젝티드 볼륨_ 을 사용하여 이를 설정하기 때문이다. + +`kubectl`에서 TokenRequest API를 사용하고 싶다면, +[서비스어카운트를 위한 API 토큰을 수동으로 생성하기](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)를 확인한다. + +쿠버네티스 컨트롤 플레인(구체적으로는 서비스어카운트 어드미션 컨트롤러)은 +파드에 프로젝티드 볼륨을 추가하고, kubelet은 컨테이너가 올바른 서비스어카운트로 인증할 수 있도록 +해당 볼륨이 토큰을 포함하는고 있는지 확인한다. + +(이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. +해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 만료가 되지 않는 것이었다.) + +아래는 실행 중인 파드에서 어떻게 보이는지에 대한 예시이다. + +```yaml +... + - name: kube-api-access- + projected: + defaultMode: 420 # 8진수 0644에 대한 10진수 값 + sources: + - serviceAccountToken: + expirationSeconds: 3607 + path: token + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace +``` + +위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. + +1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. + kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. + 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). + 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. +1. `컨피그맵(ConfigMap)` 정보는 인증 및 인가에 관한 번들을 포함한다. + 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) + 에 대한 연결을 확인할 수 있다. +1. `DownwardAPI` 정보는 파드가 포함된 네임스페이스를 검색하고, + 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다. + +이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다. + +## 추가적인 API 토큰 생성하기 {#create-token} + +{{< caution >}} +[토큰 요청](#tokenrequest-api) 메커니즘이 적합하지 않은 경우에만 수명이 긴 API 토큰을 생성한다. +토큰 요청 메커니즘은 시간 제한이 있는 토큰만을 제공하며, +토큰이 만료되기 때문에 보안에 대한 위험이 적다. +{{< /caution >}} + +서비스어카운트를 위한 만료되지 않는 API 토큰을 생성하려면, +해당 서비스어카운트를 참조하는 어노테이션을 갖는 `kubernetes.io/service-account-token` 타입의 시크릿을 생성한다. +그러면 컨트롤 플레인은 장기적으로 사용 가능한 토큰을 발급하여 +시크릿을 갱신할 것이다. + +아래는 시크릿을 위한 예제 매니페스트이다. + +{{< codenew file="secret/serviceaccount/mysecretname.yaml" >}} + +이 예제에 기반한 시크릿을 생성하려면, 아래의 명령어를 실행한다. + +```shell +kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml +``` + +시크릿에 대한 자세한 사항을 확인하려면, 아래의 명령어를 실행한다. + +```shell +kubectl -n examplens describe secret mysecretname +``` + +결과는 다음과 같다. + +``` +Name: mysecretname +Namespace: examplens +Labels: +Annotations: kubernetes.io/service-account.name=myserviceaccount + kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64 + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1362 bytes +namespace: 9 bytes +token: ... +``` + +만약 `examplens` 네임스페이스에 새로운 파드를 실행한다면, 해당 파드는 방금 생성한 `myserviceaccount` +서비스 어카운트 토큰 시크릿을 사용할 수 있다. + +## 서비스어카운트 토큰 시크릿 삭제/무효화 {#delete-token} + +만약 제거하려는 토큰을 포함하는 시크릿의 이름을 알고 있다면, 아래 명령어를 실행한다. + +```shell +kubectl delete secret name-of-secret +``` + +그게 아니라면, 먼저 시크릿을 확인한다. + +```shell +# 아래 명령어는 'examplens' 네임스페이스가 존재한다고 가정한다. +kubectl -n examplens get serviceaccount/example-automated-thing -o yaml +``` + +결과는 다음과 같다. ```yaml apiVersion: v1 -kind: Secret +kind: ServiceAccount metadata: - name: mysecretname annotations: - kubernetes.io/service-account.name: myserviceaccount -type: kubernetes.io/service-account-token + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}} + creationTimestamp: "2019-07-21T07:07:07Z" + name: example-automated-thing + namespace: examplens + resourceVersion: "777" + selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing + uid: f23fd170-66f2-4697-b049-e1e266b7f835 +secrets: + - name: example-automated-thing-token-zyxwv ``` +이제 시크릿의 이름을 알았으니, 삭제한다. + ```shell -kubectl create -f ./secret.yaml -kubectl describe secret mysecretname +kubectl -n examplens delete secret/example-automated-thing-token-zyxwv ``` -#### 서비스 어카운트 토큰 시크릿 삭제/무효화 +컨트롤 플레인은 서비스어카운트에 시크릿이 누락되었음을 감지하고, +새로운 것으로 대체한다. ```shell -kubectl delete secret mysecretname +kubectl -n examplens get serviceaccount/example-automated-thing -o yaml ``` +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}} + creationTimestamp: "2019-07-21T07:07:07Z" + name: example-automated-thing + namespace: examplens + resourceVersion: "1026" + selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing + uid: f23fd170-66f2-4697-b049-e1e266b7f835 +secrets: + - name: example-automated-thing-token-4rdrh +``` + +## 정리하기 + +예제를 위해 `examplens` 네임스페이스를 생성했었다면, 아래의 명령어로 제거할 수 있다. + +```shell +kubectl delete namespace examplens +``` + +## 컨트롤 플레인의 세부 사항들 + ### 서비스어카운트 컨트롤러 -서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고 -"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다. +서비스어카운트 컨트롤러는 네임스페이스 내의 서비스어카운트들을 관리하며, +활성화된 모든 네임스페이스에 "default"라는 이름의 서비스어카운트가 존재하도록 한다. +### 토큰 컨트롤러 + +토큰 컨트롤러는 `kube-controller-manager`의 일부로써 실행되며, +비동기적으로 동작한다. + +- 서비스어카운트에 대한 생성을 감시하고, 해당 서비스어카운트 토큰 시크릿을 생성하여 + API에 대한 접근을 허용한다. +- 서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 + 토큰 시크릿을 같이 삭제한다. +- 서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 + 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다. +- 시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 + 참조 중인 항목들을 제거한다. + +서비스 어카운트 개인키 파일은 `--service-account-private-key-file` +플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 +한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. +마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를 +`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 +검증하는 데 사용될 것이다. + +## {{% heading "whatsnext" %}} + +- 자세한 내용은 [프로젝티드 볼륨](/ko/docs/concepts/storage/projected-volumes/)을 확인한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md index d975db37b1..17c1b4a0ff 100644 --- a/content/ko/docs/reference/command-line-tools-reference/_index.md +++ b/content/ko/docs/reference/command-line-tools-reference/_index.md @@ -1,4 +1,4 @@ --- title: 컴포넌트 도구 -weight: 60 +weight: 120 --- diff --git a/content/ko/examples/secret/serviceaccount/mysecretname.yaml b/content/ko/examples/secret/serviceaccount/mysecretname.yaml new file mode 100644 index 0000000000..a0a6062eb9 --- /dev/null +++ b/content/ko/examples/secret/serviceaccount/mysecretname.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: Secret +type: kubernetes.io/service-account-token +metadata: + name: mysecretname + annotations: + kubernetes.io/service-account.name: myserviceaccount From 00461e09121809c80d80bda50173ba1958e00567 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Wed, 7 Jun 2023 17:58:23 +0900 Subject: [PATCH 67/69] [ko] Update links in dev-1.26-ko.1 --- .../cluster-administration/logging.md | 4 ++-- .../manage-resources-containers.md | 2 +- .../ko/docs/concepts/configuration/secret.md | 12 +++++------ content/ko/docs/concepts/containers/_index.md | 2 +- content/ko/docs/concepts/containers/images.md | 2 +- .../concepts/scheduling-eviction/_index.md | 2 +- .../concepts/security/pod-security-policy.md | 2 +- .../security/pod-security-standards.md | 4 ++-- .../concepts/security/rbac-good-practices.md | 2 +- .../cluster-ip-allocation.md | 2 +- .../services-networking/endpoint-slices.md | 2 +- .../services-networking/service-topology.md | 2 +- .../service-traffic-policy.md | 2 +- .../concepts/services-networking/service.md | 6 +++--- content/ko/docs/concepts/workloads/_index.md | 2 +- .../concepts/workloads/controllers/job.md | 4 ++-- .../workloads/controllers/statefulset.md | 2 +- .../concepts/workloads/pods/disruptions.md | 2 +- content/ko/docs/reference/_index.md | 2 +- .../feature-gates.md | 4 ++-- .../reference/glossary/pod-security-policy.md | 2 +- .../labels-annotations-taints/_index.md | 20 +++++++++---------- .../docs/reference/networking/virtual-ips.md | 4 ++-- content/ko/docs/reference/node/_index.md | 2 +- .../setup/production-environment/_index.md | 4 ++-- .../tools/kubeadm/install-kubeadm.md | 2 +- .../extended-resource-node.md | 4 ++-- .../cpu-constraint-namespace.md | 2 +- .../manage-resources/cpu-default-namespace.md | 2 +- .../memory-constraint-namespace.md | 2 +- .../memory-default-namespace.md | 4 ++-- .../quota-memory-cpu-namespace.md | 2 +- .../manage-resources/quota-pod-namespace.md | 2 +- .../assign-memory-resource.md | 2 +- .../quality-service-pod.md | 2 +- .../debug/debug-application/debug-pods.md | 4 ++-- .../debug/debug-application/debug-service.md | 4 ++-- .../run-replicated-stateful-application.md | 2 +- content/ko/docs/tutorials/_index.md | 2 +- .../tutorials/security/cluster-level-pss.md | 4 ++-- .../docs/tutorials/security/ns-level-pss.md | 2 +- .../stateful-application/cassandra.md | 2 +- 42 files changed, 69 insertions(+), 69 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 93b93eb761..a7270c3ad9 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -344,6 +344,6 @@ CPU 및 메모리 사용량이 낮은(몇 밀리코어 수준의 CPU와 몇 메 ## {{% heading "whatsnext" %}} -* [쿠버네티스 시스템 로그](/docs/concepts/cluster-administration/system-logs/) 살펴보기. +* [쿠버네티스 시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/) 살펴보기. * [쿠버네티스 시스템 컴포넌트에 대한 추적(trace)](/docs/concepts/cluster-administration/system-traces/) 살펴보기. -* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기. \ No newline at end of file +* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기. \ No newline at end of file diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index ea0784b76e..4ffca8d5a9 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -802,7 +802,7 @@ Events: ## {{% heading "whatsnext" %}} * [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자. -* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자. +* [컨테이너와 파드에 CPU 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자. * API 레퍼런스에 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)와 [컨테이너 리소스 요구사항](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)이 어떻게 정의되어 있는지 확인한다. * XFS의 [프로젝트 쿼터](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F)에 대해 읽어보기 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 05b5fd71fe..0ade65a053 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -40,12 +40,12 @@ API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다. 1. 시크릿에 대한 최소한의 접근 권한을 지니도록 - [RBAC 규칙을 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/)한다. + [RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다. 1. 특정 컨테이너에서만 시크릿에 접근하도록 한다. 1. [외부 시크릿 저장소 제공 서비스를 사용하는 것을 고려](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)한다. 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인은 -[쿠버네티스 시크릿에 관한 좋은 관행](/docs/concepts/security/secrets-good-practices)를 참고한다. +[쿠버네티스 시크릿에 관한 좋은 관행](/ko/docs/concepts/security/secrets-good-practices/)를 참고한다. {{< /caution >}} @@ -135,10 +135,10 @@ API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 만들어진 시크릿은 [불변(immutable)](#secret-immutable)만 아니라면 수정될 수 있다. 시크릿 수정 방식은 다음과 같다. -* [`kubectl` 사용하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret) -* [설정 파일 사용하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret) +* [`kubectl` 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret) +* [설정 파일 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret) -[Kustomize 도구](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로 +[Kustomize 도구](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로 시크릿 내부의 데이터를 수정하는 것도 가능하지만, 이 경우 수정된 데이터를 지닌 새로운 `Secret` 오브젝트가 생성된다. 시크릿을 생성한 방법이나 파드에서 시크릿이 어떻게 사용되는지에 따라, @@ -1274,7 +1274,7 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한 ## {{% heading "whatsnext" %}} - 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인을 원한다면 - [쿠버네티스 시크릿을 다루는 좋은 관행들](/docs/concepts/security/secrets-good-practices)을 참고하라. + [쿠버네티스 시크릿을 다루는 좋은 관행들](/ko/docs/concepts/security/secrets-good-practices/)을 참고하라. - [`kubectl` 을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [구성 파일을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [kustomize를 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md index 9f86172de4..6b33a54672 100644 --- a/content/ko/docs/concepts/containers/_index.md +++ b/content/ko/docs/concepts/containers/_index.md @@ -18,7 +18,7 @@ content_type: concept 따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다. 쿠버네티스 클러스터에 있는 개별 {{< glossary_tooltip text="node" term_id="node" >}}는 -해당 노드에 할당된 [파드](/docs/concepts/workloads/pods/)를 +해당 노드에 할당된 [파드](/ko/docs/concepts/workloads/pods/)를 구성하는 컨테이너들을 실행한다. 파드 내부에 컨테이너들은 같은 노드에서 실행될 수 있도록 같은 곳에 위치하고 함께 스케줄된다. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 95f9a28e58..5c0aa0343b 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -207,7 +207,7 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 kubelet에서 플러그인 바이너리를 호출하여 컨테이너 이미지에 대한 레지스트리 자격증명을 동적으로 가져오도록 설정할 수 있다. 이는 프라이빗 레지스트리에서 자격증명을 가져오는 방법 중 가장 강력하며 휘발성이 있는 방식이지만, 활성화하기 위해 kubelet 수준의 구성이 필요하다. -자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다. +자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/ko/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다. ### config.json 파일 해석 {#config-json} diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index be67137582..a091758330 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -29,7 +29,7 @@ no_list: true * [동적 리소스 할당](/docs/concepts/scheduling-eviction/dynamic-resource-allocation) * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/) -* [파드 스케줄링 준비성(readiness)](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) +* [파드 스케줄링 준비성(readiness)](/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) ## 파드 중단(disruption) diff --git a/content/ko/docs/concepts/security/pod-security-policy.md b/content/ko/docs/concepts/security/pod-security-policy.md index 9106798b50..e4543030f4 100644 --- a/content/ko/docs/concepts/security/pod-security-policy.md +++ b/content/ko/docs/concepts/security/pod-security-policy.md @@ -14,7 +14,7 @@ v1.25 버전 때 쿠버네티스에서 제거되었다. 파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을 적용할 수 있다. -- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) +- [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/) - 직접 배포하고 구성할 수 있는 서드파티 어드미션 플러그인 마이그레이션에 관한 설명이 필요하다면 [파드시큐리티폴리시(PodSecurityPolicy)에서 빌트인 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp/)을 참고한다. diff --git a/content/ko/docs/concepts/security/pod-security-standards.md b/content/ko/docs/concepts/security/pod-security-standards.md index 13847be2f6..25a9c2ac7b 100644 --- a/content/ko/docs/concepts/security/pod-security-standards.md +++ b/content/ko/docs/concepts/security/pod-security-standards.md @@ -445,7 +445,7 @@ weight: 10 메커니즘이 발달함에 따라, 아래와 같이 정책별로 정의가 될 것이다. 개별 정책에 대한 시행 방식은 여기서 정의하고 있지 않는다. -[**파드 시큐리티 어드미션 컨트롤러**](/docs/concepts/security/pod-security-admission/) +[**파드 시큐리티 어드미션 컨트롤러**](/ko/docs/concepts/security/pod-security-admission/) - {{< example file="security/podsecurity-privileged.yaml" >}}특권 네임스페이스{{< /example >}} - {{< example file="security/podsecurity-baseline.yaml" >}}기본 네임스페이스{{< /example >}} @@ -506,7 +506,7 @@ v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며, 시큐리티 프로필은 컨트롤 플레인 메커니즘으로, 시큐리티 컨텍스트의 상세 설정을 비롯하여 시큐리티 컨텍스트 외부의 다른 관련된 파라미터도 적용한다. 2021년 7월부로, [파드 시큐리티 폴리시](/ko/docs/concepts/security/pod-security-policy/)는 -내장된 [파드 시큐리티 어드미션 컨트롤러](/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다. +내장된 [파드 시큐리티 어드미션 컨트롤러](/ko/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다. ### 샌드박스 파드는 어떠한가? diff --git a/content/ko/docs/concepts/security/rbac-good-practices.md b/content/ko/docs/concepts/security/rbac-good-practices.md index 024c898f44..c4918a1a86 100644 --- a/content/ko/docs/concepts/security/rbac-good-practices.md +++ b/content/ko/docs/concepts/security/rbac-good-practices.md @@ -111,7 +111,7 @@ weight: 60 더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다. 특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면, **베이스라인** 혹은 **제한된** 파드 시큐리티 스탠다드를 사용해야 한다. -이는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) +이는 [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/) 또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다. 이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야 diff --git a/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md b/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md index 8d8a609124..56d29dea1b 100644 --- a/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md +++ b/content/ko/docs/concepts/services-networking/cluster-ip-allocation.md @@ -144,5 +144,5 @@ pie showData ## {{% heading "whatsnext" %}} * [클라이언트 소스 IP 보존하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해 알아보기 -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 알아보기 +* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해 알아보기 * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 1548053a6a..20cb20f3ef 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -272,6 +272,6 @@ v1 API의 `zone` 필드로 접근할 수 있다. ## {{% heading "whatsnext" %}} -* [서비스와 애플리케이션 연결하기](/docs/concepts/services-networking/connect-applications-service/) 튜토리얼을 따라하기 +* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼을 따라하기 * [엔드포인트슬라이스 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 를 읽어보기 * [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기 \ No newline at end of file diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index a503d60120..270e0ed7f8 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -197,4 +197,4 @@ spec: ## {{% heading "whatsnext" %}} * [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)를 읽어보기. -* [서비스와 애플리케이션 연결하기](/docs/tutorials/services/connect-applications-service/)를 읽어보기. +* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 읽어보기. diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index 16f59a4068..1d64f16a72 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -64,4 +64,4 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 * [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 -* [서비스와 애플리케이션 연결하기](/docs/tutorials/services/connect-applications-service/) 를 따라하기 +* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 를 따라하기 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index bfba8f7ab0..cb80af10b1 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -153,7 +153,7 @@ spec: 백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다. 서비스의 기본 프로토콜은 -[TCP](/docs/reference/networking/service-protocols/#protocol-tcp)이다. +[TCP](/ko/docs/reference/networking/service-protocols/#protocol-tcp)이다. 다른 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다. 많은 서비스가 하나 이상의 포트를 노출해야 하기 때문에, 쿠버네티스는 서비스 오브젝트에서 다중 @@ -1187,7 +1187,7 @@ spec: 특정 클라이언트로부터의 연결이 매번 동일한 파드로 전달되도록 하고 싶다면, 클라이언트의 IP 주소 기반으로 세션 어피니티를 구성할 수 있다. -더 자세한 정보는 [세션 어피니티](/docs/reference/networking/virtual-ips/#session-affinity)를 +더 자세한 정보는 [세션 어피니티](/ko/docs/reference/networking/virtual-ips/#session-affinity)를 참고한다. ## API 오브젝트 @@ -1205,7 +1205,7 @@ spec: ## {{% heading "whatsnext" %}} -* [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 +* [서비스와 애플리케이션 연결](/ko/docs/tutorials/services/connect-applications-service/) 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index 3440a4f779..984578298d 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -62,7 +62,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마 * [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/ko/docs/tasks/run-application/run-stateless-application-deployment/) * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/) - 또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행 + 또는 [복제된 세트](/ko/docs/tasks/run-application/run-replicated-stateful-application/)로 실행 * [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) 코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는, diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 794a0cb2c4..d1ef6d745a 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -265,7 +265,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 인덱스된(Indexed) 잡과 {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 호스트네임을 사용할 수 있다. - 이를 어떻게 설정하는지에 대해 궁금하다면, [파드 간 통신을 위한 잡](/docs/tasks/job/job-with-pod-to-pod-communication/)를 확인한다. + 이를 어떻게 설정하는지에 대해 궁금하다면, [파드 간 통신을 위한 잡](/ko/docs/tasks/job/job-with-pod-to-pod-communication/)를 확인한다. - 컨테이너화된 태스크의 경우, 환경 변수 `JOB_COMPLETION_INDEX`에 있다. 각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로 @@ -505,7 +505,7 @@ spec: [가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/ [정적 작업 할당을 사용한 인덱싱된 잡]: /ko/docs/tasks/job/indexed-parallel-processing-static/ [잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/ -[파드 간 통신을 위한 잡]: /docs/tasks/job/job-with-pod-to-pod-communication/ +[파드 간 통신을 위한 잡]: /ko/docs/tasks/job/job-with-pod-to-pod-communication/ ## 고급 사용법 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 56286ae50b..2ab1fd76c9 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -458,7 +458,7 @@ spec: * 스테이트풀셋을 사용하는 방법을 알아본다. * [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다. * [스테이트풀셋으로 카산드라 배포](/ko/docs/tutorials/stateful-application/cassandra/) 예제를 따라한다. - * [복제된 스테이트풀셋 애플리케이션 구동하기](/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다. + * [복제된 스테이트풀셋 애플리케이션 구동하기](/ko/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다. * [스테이트풀셋 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다. * [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다. * [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다. diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 9a8d14ec26..1a20f15be7 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -72,7 +72,7 @@ weight: 60 - 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다. - 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및 - [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) + [스테이트풀](/ko/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체 ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용) 또는 영역 간 diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 3eb5b1fd7a..66238b37c2 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -65,7 +65,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일) * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는 - [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트 + [포트와 프로토콜](/ko/docs/reference/networking/ports-and-protocols/) 리스트 ## API 설정 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 a9e3146476..4c4eeffb92 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 @@ -419,7 +419,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `AppArmor`: 리눅스 노드에서 실행되는 파드에 대한 AppArmor 필수 접근 제어의 사용을 활성화한다. 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다. - `ContainerCheckpoint`: kubelet의 `체크포인트` API를 활성화한다. - 자세한 내용은 [kubelet 체크포인트 API](/docs/reference/node/kubelet-checkpoint-api/)를 확인한다. + 자세한 내용은 [kubelet 체크포인트 API](/ko/docs/reference/node/kubelet-checkpoint-api/)를 확인한다. - `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가 kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면, cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록 @@ -700,7 +700,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, cAdvisor가 아닌 CRI 컨테이너 런타임으로부터 수집하도록 설정한다. - `PodDisruptionConditions`: 중단(disruption)으로 인해 파드가 삭제되고 있음을 나타내는 파드 컨디션을 추가하도록 지원한다. - `PodHasNetworkCondition`: kubelet이 파드에 [파드 네트워크 준비성](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-has-network) 컨디션을 표시하도록 지원한다. -- `PodSchedulingReadiness`: 파드의 [스케줄링 준비성](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)을 제어할 수 있도록 `schedulingGates` 필드를 활성화한다. +- `PodSchedulingReadiness`: 파드의 [스케줄링 준비성](/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)을 제어할 수 있도록 `schedulingGates` 필드를 활성화한다. - `PodSecurity`: `PodSecurity` 어드미션 플러그인을 사용하도록 설정한다. - `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에 지정된 노드를 먼저 검사할지 여부를 diff --git a/content/ko/docs/reference/glossary/pod-security-policy.md b/content/ko/docs/reference/glossary/pod-security-policy.md index 444d9f70f7..bd6fdf7b9b 100644 --- a/content/ko/docs/reference/glossary/pod-security-policy.md +++ b/content/ko/docs/reference/glossary/pod-security-policy.md @@ -18,4 +18,4 @@ tags: 파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다. 파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거되었다. -그 대신에 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인을 사용한다. +그 대신에 [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인을 사용한다. diff --git a/content/ko/docs/reference/labels-annotations-taints/_index.md b/content/ko/docs/reference/labels-annotations-taints/_index.md index bc22bc9545..990ab3793f 100644 --- a/content/ko/docs/reference/labels-annotations-taints/_index.md +++ b/content/ko/docs/reference/labels-annotations-taints/_index.md @@ -145,7 +145,7 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블 리밋레인지를 정의한 뒤에 배포된 파드들은 이러한 한도가 적용된다. `kubernetes.io/limit-ranger` 어노테이션은 파드에 대해 리소스 기본값이 성공적으로 적용되었다고 기록한다. -자세한 내용은 [리밋레인지](/docs/concepts/policy/limit-range)를 확인한다. +자세한 내용은 [리밋레인지](/ko/docs/concepts/policy/limit-range/)를 확인한다. ## beta.kubernetes.io/arch (사용 중단됨) @@ -401,8 +401,8 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo 적용 대상: 엔드포인트슬라이스(EndpointSlices) -쿠버네티스는 이 레이블을 사용하여 [엔드포인트슬라이스](/docs/concepts/services-networking/endpoint-slices/)와 -[서비스](/docs/concepts/services-networking/service/)를 결합한다. +쿠버네티스는 이 레이블을 사용하여 [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)와 +[서비스](/ko/docs/concepts/services-networking/service/)를 결합한다. 이 레이블은 엔드포인트슬라이스가 지원하는 서비스의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다. 모든 엔드포인트슬라이스는 이 레이블을 @@ -531,7 +531,7 @@ kube-controller-manager의 잡(Job) 컨트롤러는 적용 대상: 엔드포인트(Endpoints) -{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은, 연결된 {{< glossary_tooltip text="서비스" term_id="service" >}}에 1000개 이상의 엔드포인트가 있는 경우, 이 어노테이션을 [엔드포인트](/docs/concepts/services-networking/service/#endpoints) 오브젝트에 추가한다. 이 어노테이션은 엔드포인트의 용량이 초과되었거나 엔드포인트의 수가 1000개로 잘렸음을 나타낸다. +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은, 연결된 {{< glossary_tooltip text="서비스" term_id="service" >}}에 1000개 이상의 엔드포인트가 있는 경우, 이 어노테이션을 [엔드포인트](/ko/docs/concepts/services-networking/service/#endpoints) 오브젝트에 추가한다. 이 어노테이션은 엔드포인트의 용량이 초과되었거나 엔드포인트의 수가 1000개로 잘렸음을 나타낸다. 백엔드 엔드포인트의 수가 1000개 미만이면, 컨트롤 플레인은 이 어노테이션을 제거한다. @@ -651,7 +651,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 모든 파드의 생성을 금지한다. -더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/ko/docs/concepts/security/pod-security-admission)을 참고한다. ## pod-security.kubernetes.io/enforce-version @@ -664,7 +664,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/) 정책의 버전이 결정된다. -더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/ko/docs/concepts/security/pod-security-admission)을 참고한다. ## pod-security.kubernetes.io/audit @@ -678,7 +678,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을 방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다. -더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/ko/docs/concepts/security/pod-security-admission)을 참고한다. ## pod-security.kubernetes.io/audit-version @@ -691,7 +691,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/) 정책의 버전이 결정된다. -더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/ko/docs/concepts/security/pod-security-admission)을 참고한다. ## pod-security.kubernetes.io/warn @@ -707,7 +707,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 객체를 만들거나 업데이트할 때에도 경고가 표시된다. -더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/ko/docs/concepts/security/pod-security-admission)을 참고한다. ## pod-security.kubernetes.io/warn-version @@ -721,7 +721,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 객체를 만들거나 업데이트할 때에도 경고가 표시된다. -더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/ko/docs/concepts/security/pod-security-admission)을 참고한다. ### kubernetes.io/psp (사용 중단됨) {#kubernetes-io-psp} diff --git a/content/ko/docs/reference/networking/virtual-ips.md b/content/ko/docs/reference/networking/virtual-ips.md index ad201664f1..73882691ec 100644 --- a/content/ko/docs/reference/networking/virtual-ips.md +++ b/content/ko/docs/reference/networking/virtual-ips.md @@ -10,7 +10,7 @@ weight: 50 실행한다(`kube-proxy`를 대체하는 구성요소를 직접 배포한 경우가 아니라면). `kube-proxy`는 -[`ExternalName`](/docs/concepts/services-networking/service/#externalname) 외의 `type`의 +[`ExternalName`](/ko/docs/concepts/services-networking/service/#externalname) 외의 `type`의 {{< glossary_tooltip term_id="service" text="서비스">}}를 위한 _가상 IP_ 메커니즘의 구현을 담당한다. @@ -276,7 +276,7 @@ kube-proxy는 종료 중인 해당 엔드포인트로 트래픽을 전달한다. ## {{% heading "whatsnext" %}} 서비스에 대해 더 알아보려면, -[서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/)을 읽어 본다. +[서비스와 애플리케이션 연결](/ko/docs/tutorials/services/connect-applications-service/)을 읽어 본다. 또한, diff --git a/content/ko/docs/reference/node/_index.md b/content/ko/docs/reference/node/_index.md index 50822eb357..a7768c1d89 100644 --- a/content/ko/docs/reference/node/_index.md +++ b/content/ko/docs/reference/node/_index.md @@ -6,7 +6,7 @@ no_list: true 이 섹션에서는 노드에 관한 다음의 레퍼런스 주제를 다룬다. -* kubelet의 [체크포인트 API](/docs/reference/node/kubelet-checkpoint-api/) +* kubelet의 [체크포인트 API](/ko/docs/reference/node/kubelet-checkpoint-api/) * [도커심 제거 및 CRI 호환 런타임 사용에 대한 글](/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) 목록 다음과 같은 다른 쿠버네티스 문서에서도 diff --git a/content/ko/docs/setup/production-environment/_index.md b/content/ko/docs/setup/production-environment/_index.md index e62c89c09b..7f4e72e53b 100644 --- a/content/ko/docs/setup/production-environment/_index.md +++ b/content/ko/docs/setup/production-environment/_index.md @@ -271,7 +271,7 @@ etcd 백업 계획을 세우려면 제한을 상속할 수도 있다. - *DNS 요청에 대한 대비*: 워크로드가 대규모로 확장될 것으로 예상된다면, DNS 서비스도 확장할 준비가 되어 있어야 한다. - [클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다. + [클러스터의 DNS 서비스 오토스케일링](/ko/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다. - *추가적인 서비스 어카운트 생성*: 사용자 계정은 *클러스터*에서 사용자가 무엇을 할 수 있는지 결정하는 반면에, 서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. 기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다. @@ -303,6 +303,6 @@ etcd 백업 계획을 세우려면 [인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 사용자 관리 방법을 구성한다. - [자원 제한](/ko/docs/tasks/administer-cluster/manage-resources/), - [DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), + [DNS 오토스케일링](/ko/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), [서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 애플리케이션 워크로드의 실행에 대비한다. 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 22fe417acd..0de4f7a4d1 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 @@ -46,7 +46,7 @@ card: 경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다. ## 필수 포트 확인 {#check-required-ports} -[필수 포트들](/ko/docs/reference/ports-and-protocols/)은 +[필수 포트들](/ko/docs/reference/networking/ports-and-protocols/)은 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야 한다. 다음과 같이 netcat과 같은 도구를 이용하여 포트가 열려 있는지 확인해 볼 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/extended-resource-node.md b/content/ko/docs/tasks/administer-cluster/extended-resource-node.md index c9aed07263..23ee82e5ef 100644 --- a/content/ko/docs/tasks/administer-cluster/extended-resource-node.md +++ b/content/ko/docs/tasks/administer-cluster/extended-resource-node.md @@ -105,7 +105,7 @@ Capacity: ``` 이제, 애플리케이션 개발자는 특정 개수의 동글을 요청하는 파드를 -만들 수 있다. [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)를 +만들 수 있다. [컨테이너에 확장 리소스 할당하기](/ko/docs/tasks/configure-pod-container/extended-resource/)를 참고한다. ## 토론 @@ -198,7 +198,7 @@ kubectl describe node | grep dongle ### 애플리케이션 개발자를 위한 문서 -* [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/) +* [컨테이너에 확장 리소스 할당하기](/ko/docs/tasks/configure-pod-container/extended-resource/) ### 클러스터 관리자를 위한 문서 diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 9a48a1da05..d4ba8e3f29 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -275,6 +275,6 @@ kubectl delete namespace constraints-cpu-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너와 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너와 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 1a066c6a86..aebfb1290a 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -210,6 +210,6 @@ kubectl delete namespace default-cpu-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 50f67d8bc0..2462809865 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -274,6 +274,6 @@ kubectl delete namespace constraints-mem-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index 8b36c28afc..1420ef904b 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -170,7 +170,7 @@ resources: {{< note >}} `리밋레인지`는 적용되는 기본 값의 일관성을 검사하지 않는다. 이는 `리밋레인지`에 의해 설정된 _상한_의 기본값이 클라이언트가 API 서버에 제출하는 사양의 컨테이너에 대해 지정된 _요청량_ 값보다 작을 수 있음을 의미한다. 이 경우, 최종 파드는 스케줄링할 수 없다. -자세한 내용은 [리밋 레인지 개요](/docs/concepts/policy/limit-range/#constraints-on-resource-limits-and-requests)를 참조한다. +자세한 내용은 [리밋 레인지 개요](/ko/docs/concepts/policy/limit-range/#constraints-on-resource-limits-and-requests)를 참조한다. {{< /note >}} @@ -226,6 +226,6 @@ kubectl delete namespace default-mem-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index 892566050a..89dc826e2c 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -183,6 +183,6 @@ kubectl delete namespace quota-mem-cpu-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index c525db0323..8583f97b7b 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -140,6 +140,6 @@ kubectl delete namespace quota-pod-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index c80e13984a..93948f34ce 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -338,7 +338,7 @@ kubectl delete namespace mem-example ### 앱 개발자들을 위한 -* [CPU 리소스를 컨테이너와 파드에 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [CPU 리소스를 컨테이너와 파드에 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) * [파드에 서비스 품질 설정](/ko/docs/tasks/configure-pod-container/quality-service-pod/) diff --git a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md index b8b2448f04..28000379df 100644 --- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md @@ -254,7 +254,7 @@ kubectl delete namespace qos-example * [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/) -* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [컨테이너 및 파드 CPU 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/) ### 클러스터 관리자를 위한 문서 diff --git a/content/ko/docs/tasks/debug/debug-application/debug-pods.md b/content/ko/docs/tasks/debug/debug-application/debug-pods.md index b16d998cb3..0b56847e91 100644 --- a/content/ko/docs/tasks/debug/debug-application/debug-pods.md +++ b/content/ko/docs/tasks/debug/debug-application/debug-pods.md @@ -146,12 +146,12 @@ kubectl get pods --selector=name=nginx,type=frontend #### 네트워크 트래픽이 포워드되지 않는 경우 -[서비스 디버깅하기](/docs/tasks/debug/debug-application/debug-service/)에서 더 많은 정보를 확인한다. +[서비스 디버깅하기](/ko/docs/tasks/debug/debug-application/debug-service/)에서 더 많은 정보를 확인한다. ## {{% heading "whatsnext" %}} 위의 방법 중 어떤 것으로도 문제가 해결되지 않는다면, -[서비스 디버깅하기 문서](/docs/tasks/debug/debug-application/debug-service/)를 참조하여 +[서비스 디버깅하기 문서](/ko/docs/tasks/debug/debug-application/debug-service/)를 참조하여 `서비스`가 실행 중인지, 서비스에 `엔드포인트`가 있는지, `파드`가 실제로 서빙 중인지 확인한다. 예를 들어, DNS가 실행 중이고, iptables 규칙이 설정되어 있고, kube-proxy가 정상적으로 동작하는 것으로 보이는 상황이라면, 위와 같은 사항을 확인해 볼 수 있다. diff --git a/content/ko/docs/tasks/debug/debug-application/debug-service.md b/content/ko/docs/tasks/debug/debug-application/debug-service.md index ad4ede5b3e..b89cd9a9ea 100644 --- a/content/ko/docs/tasks/debug/debug-application/debug-service.md +++ b/content/ko/docs/tasks/debug/debug-application/debug-service.md @@ -219,7 +219,7 @@ spec: `hostnames-*` 파드로 들어오는 트래픽에 영향을 줄 수 있는 네트워크 폴리시 인그레스 규칙을 배포하는 경우, 이를 검토해야 한다. -자세한 내용은 [Network Policies](/docs/concepts/services-networking/network-policies/)를 참고한다. +자세한 내용은 [Network Policies](/ko/docs/concepts/services-networking/network-policies/)를 참고한다. ## 서비스가 DNS 이름으로 작동하는가? @@ -442,7 +442,7 @@ hostnames-632524106-tlaok 1/1 Running 0 1h "RESTARTS" 열은 파드가 자주 충돌하지 않거나 다시 시작되지 않음을 나타낸다. 잦은 재시작은 간헐적인 연결 문제를 발생할 수 있다. -재시작 횟수가 높으면, [파드를 디버깅하는](/docs/tasks/debug/debug-application/debug-pods/) 방법에 대해 참고한다. +재시작 횟수가 높으면, [파드를 디버깅하는](/ko/docs/tasks/debug/debug-application/debug-pods/) 방법에 대해 참고한다. 쿠버네티스 시스템 내부에는 모든 서비스의 셀렉터를 평가하고 그 결과를 해당 엔드포인트 오브젝트에 저장하는 제어 루프가 있다. diff --git a/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md index ed38bbb053..6efc2b0fa4 100644 --- a/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ko/docs/tasks/run-application/run-replicated-stateful-application.md @@ -300,7 +300,7 @@ kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\ ### 준비성 프로브 고장내기 -`mysql` 컨테이너의 [준비성 프로브](/ko/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)는 +`mysql` 컨테이너의 [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)는 쿼리를 실행할 수 있는지를 확인하기 위해 `mysql -h 127.0.0.1 -e 'SELECT 1'` 명령을 실행한다. diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index a96a42f927..4643e15d9f 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -49,7 +49,7 @@ content_type: concept ## 서비스 -* [서비스들로 애플리케이션에 접속하기](/docs/tutorials/services/connect-applications-service/) +* [서비스들로 애플리케이션에 접속하기](/ko/docs/tutorials/services/connect-applications-service/) * [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/) ## 보안 diff --git a/content/ko/docs/tutorials/security/cluster-level-pss.md b/content/ko/docs/tutorials/security/cluster-level-pss.md index 7b5bb7be80..0ce80314ab 100644 --- a/content/ko/docs/tutorials/security/cluster-level-pss.md +++ b/content/ko/docs/tutorials/security/cluster-level-pss.md @@ -32,7 +32,7 @@ weight: 10 ## 적용할 알맞은 파드 시큐리티 스탠다드 선택하기 -[파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)을 이용하여 +[파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/)을 이용하여 `enforce`, `audit`, 또는 `warn` 모드 중 하나로 내장 [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)를 적용할 수 있다. @@ -330,6 +330,6 @@ weight: 10 4. kubectl context를 새로 생성한 클러스터에 설정 5. 최소한의 파드 구성을 위한 yaml 파일을 생성 6. 해당 파일을 적용하여 새 클러스터에 파드를 생성 -- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) +- [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/) - [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/) - [파드 시큐리티 스탠다드를 네임스페이스 수준에 적용하기](/ko/docs/tutorials/security/ns-level-pss/) diff --git a/content/ko/docs/tutorials/security/ns-level-pss.md b/content/ko/docs/tutorials/security/ns-level-pss.md index aefb3f1cdc..c72fe93173 100644 --- a/content/ko/docs/tutorials/security/ns-level-pss.md +++ b/content/ko/docs/tutorials/security/ns-level-pss.md @@ -169,6 +169,6 @@ namespace/example created `restricted` 파드 시큐리티 스탠다드는 `warn` 및 `audit` 모드로 적용 4. 해당 파드 시큐리티 스탠다드가 적용된 상태에서 새로운 파드를 생성 -- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) +- [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/) - [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/) - [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/) diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 37d794184f..4cef8f6442 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -95,7 +95,7 @@ cassandra ClusterIP None 9042/TCP 45s ``` `cassandra` 서비스가 보이지 않는다면, 이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한 -[서비스 디버깅하기](/docs/tasks/debug/debug-application/debug-service/)를 +[서비스 디버깅하기](/ko/docs/tasks/debug/debug-application/debug-service/)를 읽어보자. ## 카산드라 링을 생성하는 스테이트풀셋 이용하기 From 77ce168708348fcf54dffd024f35de84572b232d Mon Sep 17 00:00:00 2001 From: Kevin Park Date: Sun, 21 May 2023 17:31:26 +0900 Subject: [PATCH 68/69] [ko] translate leases.md into Korean --- .../ko/docs/concepts/architecture/leases.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 content/ko/docs/concepts/architecture/leases.md diff --git a/content/ko/docs/concepts/architecture/leases.md b/content/ko/docs/concepts/architecture/leases.md new file mode 100644 index 0000000000..16510e10c3 --- /dev/null +++ b/content/ko/docs/concepts/architecture/leases.md @@ -0,0 +1,80 @@ +--- +title: 리스(Lease) +content_type: concept +weight: 30 +--- + + + +분산 시스템에는 종종 공유 리소스를 잠그고 노드 간의 활동을 조정하는 메커니즘을 제공하는 "리스(Lease)"가 필요하다. +쿠버네티스에서 "리스" 개념은 `coordination.k8s.io` API 그룹에 있는 `Lease` 오브젝트로 표현되며, +노드 하트비트 및 컴포넌트 수준의 리더 선출과 같은 시스템 핵심 기능에서 사용된다. + + + +## 노드 하트비트 + +쿠버네티스는 리스 API를 사용하여 kubelet 노드의 하트비트를 쿠버네티스 API 서버에 전달한다. +모든 `노드`에는 같은 이름을 가진 `Lease` 오브젝트가 `kube-node-lease` 네임스페이스에 존재한다. +내부적으로, 모든 kubelet 하트비트는 이 `Lease` 오브젝트에 대한 업데이트 요청이며, +이 업데이트 요청은 `spec.renewTime` 필드를 업데이트한다. +쿠버네티스 컨트롤 플레인은 이 필드의 타임스탬프를 사용하여 해당 `노드`의 가용성을 확인한다. + +자세한 내용은 [노드 리스 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats)를 참조한다. + +## 리더 선출 + +리스는 쿠버네티스에서도 특정 시간 동안 컴포넌트의 인스턴스 하나만 실행되도록 보장하는 데에도 사용된다. +이는 구성 요소의 한 인스턴스만 활성 상태로 실행되고 다른 인스턴스는 대기 상태여야 하는 +`kube-controller-manager` 및 `kube-scheduler`와 같은 컨트롤 플레인 컴포넌트의 +고가용성 설정에서 사용된다. + +## API 서버 신원 + +{{< feature-state for_k8s_version="v1.26" state="beta" >}} + +쿠버네티스 v1.26부터, 각 `kube-apiserver`는 리스 API를 사용하여 시스템의 나머지 부분에 자신의 신원을 게시한다. +그 자체로는 특별히 유용하지는 않지만, 이것은 클라이언트가 쿠버네티스 컨트롤 플레인을 운영 중인 `kube-apiserver` 인스턴스 수를 +파악할 수 있는 메커니즘을 제공한다. +kube-apiserver 리스의 존재는 향후 각 kube-apiserver 간의 조정이 필요할 때 +기능을 제공해 줄 수 있다. + +각 kube-apiserver가 소유한 리스는 `kube-system` 네임스페이스에서`kube-apiserver-`라는 이름의 +리스 오브젝트를 확인하여 볼 수 있다. 또는 `k8s.io/component=kube-apiserver` 레이블 설렉터를 사용하여 볼 수도 있다. + +```shell +$ kubectl -n kube-system get lease -l k8s.io/component=kube-apiserver +NAME HOLDER AGE +kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4 5m33s +kube-apiserver-dz2dqprdpsgnm756t5rnov7yka kube-apiserver-dz2dqprdpsgnm756t5rnov7yka_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s +kube-apiserver-fyloo45sdenffw2ugwaz3likua kube-apiserver-fyloo45sdenffw2ugwaz3likua_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s +``` + +리스 이름에 사용된 SHA256 해시는 kube-apiserver가 보는 OS 호스트 이름을 기반으로 한다. +각 kube-apiserver는 클러스터 내에서 고유한 호스트 이름을 사용하도록 구성해야 한다. +동일한 호스트명을 사용하는 새로운 kube-apiserver 인스턴스는 새 리스 오브젝트를 인스턴스화하는 대신 새로운 소유자 ID를 사용하여 기존 리스를 차지할 수 있다. +kube-apiserver가 사용하는 호스트네임은 `kubernetes.io/hostname` 레이블의 값을 확인하여 확인할 수 있다. + +```shell +$ kubectl -n kube-system get lease kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a -o yaml +``` + +```yaml +apiVersion: coordination.k8s.io/v1 +kind: Lease +metadata: + creationTimestamp: "2022-11-30T15:37:15Z" + labels: + k8s.io/component: kube-apiserver + kubernetes.io/hostname: kind-control-plane + name: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a + namespace: kube-system + resourceVersion: "18171" + uid: d6c68901-4ec5-4385-b1ef-2d783738da6c +spec: + holderIdentity: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4 + leaseDurationSeconds: 3600 + renewTime: "2022-11-30T18:04:27.912073Z" +``` + +더 이상 존재하지 않는 kube-apiserver의 만료된 임대는 1시간 후에 새로운 kube-apiserver에 의해 가비지 컬렉션된다. From 256c2beffccf692fae0102576c18686fdba5534f Mon Sep 17 00:00:00 2001 From: dewble Date: Fri, 14 Apr 2023 22:53:18 +0900 Subject: [PATCH 69/69] Translate docs/tasks/administer-cluster/kubelet-config-file into Korean Signed-off-by: dewble --- .../administer-cluster/kubelet-config-file.md | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 content/ko/docs/tasks/administer-cluster/kubelet-config-file.md diff --git a/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md b/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md new file mode 100644 index 0000000000..9fd905fc0d --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubelet-config-file.md @@ -0,0 +1,73 @@ +--- +#reviewers: +# - mtaufen +# - dawnchen +title: 구성 파일을 통해 Kubelet 파라미터 설정하기 +content_type: task +--- + + + +커맨드 라인 플래그 대신 디스크 상의 구성 파일을 통해 +Kubelet의 구성 파라미터 하위 집합을 설정할 수 있다. + +구성 파일을 통해 파라미터를 제공하는 것은 +노드 배포 및 구성 관리를 간소화하기 때문에 권장되는 접근 방식이다. + + + +## 구성 파일 만들기 + +파일을 통해 구성할 수 있는 +Kubelet 구성의 하위 집합은 +[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) +구조체에 의해 정의된다. + +구성 파일은 이 구조체의 파라미터를 반드시 JSON 또는 YAML로 표현한 파일이어야 한다. +Kubelet이 파일에 읽기 권한이 있는지 확인한다. + +다음은 이러한 파일에 대한 예시를 보여준다. +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +address: "192.168.0.8", +port: 20250, +serializeImagePulls: false, +evictionHard: + memory.available: "200Mi" +``` + +이 예제에서, Kubelet은 192.168.0.8 IP 주소와 20250 포트에서 동작하고, 이미지를 병렬로 가져오고, +사용 가능 메모리가 200Mi 아래로 떨어지면 파드를 축출하도록 구성되어 있다. +플래그에 의해 재정의(overridden)되지 않는한, 다른 모든 Kubelet 구성은 기본 제공 기본값으로 유지된다. +구성 파일과 동일한 값을 대상으로 하는 커맨드 라인 플래그는 해당 값을 재정의 한다. + +## 구성 파일을 통해 구성된 Kubelet 프로세스 시작하기 + +{{< note >}} +kubeadm을 사용하여 클러스터를 초기화하는 경우 `kubeadmin init`으로 클러스터를 생성하는 동안 kubelet-config를 사용해야 한다. +자세한 내용은 [kubeadm을 사용하여 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/)를 참고한다. +{{< /note >}} + +Kubelet의 구성 파일 경로로 설정된 `--config` 플래그를 사용하여 Kubelet을 시작하면 +Kubelet이 이 파일에서 구성을 불러온다. + +구성 파일과 동일한 값을 대상으로 하는 커맨드 라인 플래그는 해당 값을 재정의한다는 점을 유의한다. +이렇게 하면 커맨드 라인 API와의 이전 버전과의 호환성을 보장할 수 있다. + +Kubelet 구성 파일의 상대 파일 경로는 +Kubelet 구성 파일의 위치를 기준으로 확인되는 반면, 커맨드 라인 플래그의 상대 경로는 +Kubelet의 현재 작업 디렉터리를 기준으로 확인된다는 점에 유의한다. + +일부 기본값은 커맨드 라인 플래그와 Kubelet 구성 파일 간에 다르다는 점에 유의한다. +`--config`가 제공되고 명령줄을 통해 값을 지정하지 않은 경우, +`KubeletConfiguration` 버전의 기본값이 적용된다. +위 예제의 버전은 `kubelet.config.k8s.io/v1beta1`이다. + + + +## {{% heading "whatsnext" %}} + +- Kubelet 구성에 대한 자세한 내용은 + [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) + 를 참고한다.
    {{ T "cve_table" }} {{ T "cve_table_date_before" }}{{ $feed._kubernetes_io.updated_at | time.Format ( T "cve_table_date_format" ) }}{{ T "cve_table_date_after" }}{{ T "cve_table" }} {{ printf (T "cve_table_date_format_string") ($feed._kubernetes_io.updated_at | time.Format (T "cve_table_date_format")) }}
    {{ T "cve_id" }}