From 0cc9ae1a503b3526c4f7f3d3eab9aa8065a59adc Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Sun, 10 Oct 2021 00:42:12 +0900 Subject: [PATCH 01/43] Update outdated in dev-1.22-ko.2 (Task M3-M5) --- .../cluster-administration/logging.md | 8 +++--- .../cluster-administration/networking.md | 25 +++---------------- 2 files changed, 7 insertions(+), 26 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 5ae2aafffd..39ef2f2dcb 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -17,8 +17,8 @@ weight: 60 -클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 -로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, +클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. 쿠버네티스가 +로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만, 쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. ## 쿠버네티스의 기본 로깅 @@ -136,7 +136,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo 각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다. -로깅 에이전트는 모든 노드에서 실행해야 하므로, 에이전트는 +로깅 에이전트는 모든 노드에서 실행되어야 하므로, 에이전트를 `DaemonSet` 으로 동작시키는 것을 추천한다. 노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다. @@ -262,4 +262,4 @@ fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](http ![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png) -모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. +애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index b72d38a360..3f6e103ba7 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -1,4 +1,6 @@ --- + + title: 클러스터 네트워킹 content_type: concept weight: 50 @@ -89,18 +91,6 @@ VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모 프로젝트 [Antrea](https://github.com/vmware-tanzu/antrea)는 쿠버네티스 고유의 오픈소스 쿠버네티스 네트워킹 솔루션이다. 네트워킹 데이터 플레인으로 Open vSwitch를 활용한다. Open vSwitch는 리눅스와 윈도우를 모두 지원하는 고성능의 프로그래밍이 가능한 가상 스위치이다. Antrea는 Open vSwitch를 통해 쿠버네티스 네트워크 정책을 고성능의 효율적인 방식으로 구현할 수 있다. Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다. -### Apstra의 AOS - -[AOS](https://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다. - -AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다. - -AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워크 정책을 신속하게 변경할 수 있는 풍부한 REST API 엔드포인트 셋을 제공한다. 네트워크 설계에 사용된 AOS 그래프 모델을 워크로드 프로비저닝과 통합하여 프라이빗 클라우드와 퍼블릭 클라우드 모두에 대한 엔드-투-엔드 관리 시스템을 향상시킬 수 있다. - -AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다. - -AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. https://www.apstra.com/products/how-it-works/ - ### 쿠버네티스용 AWS VPC CNI [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)는 쿠버네티스 클러스터를 위한 통합된 AWS 버추얼 프라이빗 클라우드(Virtual Private Cloud, VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량과 가용성, 낮은 레이턴시(latency) 그리고 최소 네트워크 지터(jitter)를 제공한다. 또한, 사용자는 쿠버네티스 클러스터를 구축하기 위한 기존의 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있다. 여기에는 VPC 플로우 로그, VPC 라우팅 정책과 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함되어 있다. @@ -114,15 +104,6 @@ AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다 Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni)에서 기본적으로 사용할 수 있다. - -### Big Switch Networks의 빅 클라우드 패브릭(Big Cloud Fabric) - -[빅 클라우드 패브릭](https://www.bigswitch.com/container-network-automation)은 클라우드 네이티브 네트워킹 아키텍처로, 프라이빗 클라우드/온-프레미스 환경에서 쿠버네티스를 실행하도록 디자인되었다. 통합된 물리 및 가상 SDN을 사용하여, 빅 클라우드 패브릭은 로드 밸런싱, 가시성, 문제 해결, 보안 정책 및 컨테이너 트래픽 모니터링과 같은 내재한 컨테이너 네트워킹 문제를 해결한다. - -빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다. - -가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. - ### 캘리코 [캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다. @@ -267,7 +248,7 @@ Lars Kellogg-Stedman이 제공하는 [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. -Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. +Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. ### OVN4NFV-K8s-Plugin (OVN 기반의 CNI 컨트롤러 & 플러그인) From 1a256a68cdd557128f62b04f04658b624ef3e9a5 Mon Sep 17 00:00:00 2001 From: June Yi Date: Sun, 10 Oct 2021 01:52:21 +0900 Subject: [PATCH 02/43] [ko] Update outdated in dev-1.22-ko.2 (Task M6) --- content/ko/docs/concepts/configuration/configmap.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 841feb8fb3..0225ba7778 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -61,6 +61,11 @@ v1.19부터 컨피그맵 정의에 `immutable` 필드를 추가하여 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 있어야 한다. +{{< note >}} +{{< glossary_tooltip text="스태틱(static) 파드" term_id="static-pod" >}}의 `spec`은 컨피그맵 +또는 다른 API 오브젝트를 참조할 수 없다. +{{< /note >}} + 다음은 단일 값을 가진 키와, 값이 구성 형식의 일부처럼 보이는 키를 가진 컨피그맵의 예시이다. From 850144b6ef78531d85c1cb73d2b638efdb8dc3a9 Mon Sep 17 00:00:00 2001 From: June Yi Date: Sun, 10 Oct 2021 02:19:08 +0900 Subject: [PATCH 03/43] [ko] Update outdated content in dev-1.22-ko.2 (Task M7) --- .../configuration/manage-resources-containers.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 3084651390..fa7ec69fc9 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -182,8 +182,8 @@ kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을 플래그의 값으로 사용된다. - 이 `spec.containers[].resources.limits.cpu` 값은 밀리코어 값으로 변환되고 - 100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 총 CPU - 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다. + 100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 마이크로초 단위의 + 총 CPU 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다. {{< note >}} 기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다. @@ -338,6 +338,9 @@ spec: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: @@ -345,6 +348,12 @@ spec: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + volumes: + - name: ephemeral + emptyDir: {} ``` ### 임시-스토리지 요청이 있는 파드의 스케줄링 방법 From 4499017f7c6f0a3ab3a12189ae2f308400732d7f Mon Sep 17 00:00:00 2001 From: June Yi Date: Sun, 10 Oct 2021 02:44:22 +0900 Subject: [PATCH 04/43] [ko] Update outdated content in dev-1.22-ko.2 (Task M8) --- .../docs/concepts/configuration/overview.md | 26 ------------------- 1 file changed, 26 deletions(-) diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index f89d873a37..64b6bc3395 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -73,32 +73,6 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. -## 컨테이너 이미지 - -[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다. - -- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다. - -- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다. - -- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_. - -- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_. - -- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다. - -{{< note >}} -컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, `<이미지 이름>:<태그>` 를 `<이미지 이름>@<다이제스트>` (예시 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)로 변경해서 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다. -{{< /note >}} - -{{< note >}} -운영 환경에서 컨테이너를 생성할 때 `:latest` 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다. -{{< /note >}} - -{{< note >}} -레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다. -{{< /note >}} - ## kubectl 사용하기 - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. From 0c3dbcb2e898e83f425f465c21e887c3a0f647ca Mon Sep 17 00:00:00 2001 From: June Yi Date: Sun, 10 Oct 2021 21:08:11 +0900 Subject: [PATCH 05/43] [ko] Update outdated content of dev-1.22-ko.2 (Task M9) --- .../ko/docs/concepts/configuration/secret.md | 31 +++++++++++++------ 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 330e89edac..8c0630c4b2 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -77,7 +77,7 @@ weight: 30 시크릿을 생성할 때, [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) 리소스의 `type` 필드를 사용하거나, (활용 가능하다면) `kubectl` 의 유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다. -시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다. +시크릿 타입은 여러 종류의 기밀 데이터를 프로그래밍 방식으로 용이하게 처리하기 위해 사용된다. 쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다. 이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에 @@ -212,7 +212,8 @@ data: kubectl create secret docker-registry secret-tiger-docker \ --docker-username=tiger \ --docker-password=pass113 \ - --docker-email=tiger@acme.com + --docker-email=tiger@acme.com \ + --docker-server=my-registry.example:5000 ``` 이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다. @@ -222,15 +223,21 @@ kubectl create secret docker-registry secret-tiger-docker \ ```json { - "auths": { - "https://index.docker.io/v1/": { - "username": "tiger", - "password": "pass113", - "email": "tiger@acme.com", - "auth": "dGlnZXI6cGFzczExMw==" - } - } + "apiVersion": "v1", + "data": { + ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" + }, + "kind": "Secret", + "metadata": { + "creationTimestamp": "2021-07-01T07:30:59Z", + "name": "secret-tiger-docker", + "namespace": "default", + "resourceVersion": "566718", + "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" + }, + "type": "kubernetes.io/dockerconfigjson" } + ``` ### 기본 인증 시크릿 @@ -834,6 +841,9 @@ kubelet은 API 서버에서 시크릿을 가져오는 파드에 대한 파드가 포함된다. kubelet의 `--manifest-url` 플래그, `--config` 플래그 또는 kubectl의 REST API(이 방법들은 파드를 생성하는 일반적인 방법이 아님)로 생성된 파드는 포함하지 않는다. +{{< glossary_tooltip text="스태틱(static) 파드" term_id="static-pod" >}}의 `spec`은 컨피그맵 +또는 다른 API 오브젝트를 참조할 수 없다. + 시크릿은 optional(선택 사항)로 표시되지 않는 한 파드에서 환경 변수로 사용되기 전에 생성되어야 한다. 존재하지 않는 시크릿을 @@ -1252,3 +1262,4 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 +- [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기 From f5270d64c8b8da8df5b061d4c21266d8c9068f29 Mon Sep 17 00:00:00 2001 From: June Yi Date: Sun, 10 Oct 2021 21:15:39 +0900 Subject: [PATCH 06/43] [ko] Update outdated content in dev-1.22-ko.2 (Task M10) --- content/ko/docs/concepts/containers/container-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 749eb6fbb8..18ed0aadd3 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> FOO_SERVICE_PORT=<서비스가 동작 중인 포트> ``` -서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. +서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. From 25837b559997f5f56c1d04fdc836898e69ab9e3f Mon Sep 17 00:00:00 2001 From: June Yi Date: Mon, 11 Oct 2021 10:42:18 +0900 Subject: [PATCH 07/43] [ko] Update outdated content in dev-1.22-ko.2 (Task M12) --- .../api-extension/apiserver-aggregation.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) 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 a2326c71dd..7658464ec0 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 @@ -1,5 +1,5 @@ --- -title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기 +title: 쿠버네티스 API 애그리게이션 레이어(aggregation layer) @@ -11,7 +11,7 @@ weight: 10 애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다. -추가 API는 [서비스-카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. +추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. 애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다. @@ -34,5 +34,6 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 * 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). * 다음에, [확장 API 서버를 구성해서](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. -* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. -* [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. +* API 레퍼런스에서 [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)에 대해 읽어본다. + +대안으로, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. From b48071ad7aa0cddbeab2ed4131ea8a53edc857df Mon Sep 17 00:00:00 2001 From: June Yi Date: Mon, 11 Oct 2021 13:30:44 +0900 Subject: [PATCH 08/43] [ko] Update custom-resources.md refs #30000 --- .../api-extension/custom-resources.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) 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 0357ac7619..e6e0203eb9 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 @@ -35,11 +35,10 @@ weight: 10 커스텀 리소스를 *커스텀 컨트롤러* 와 결합하면, 커스텀 리소스가 진정한 _선언적(declarative) API_ 를 제공하게 된다. -[선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 리소스의 의도한 상태를 -_선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트의 현재 상태를 의도한 상태와 -동기화 상태로 유지하려고 한다. 컨트롤러는 구조화된 데이터를 사용자가 -원하는 상태의 레코드로 해석하고 지속적으로 -이 상태를 유지한다. +쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 +책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다. +쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다. +이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다. 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고 업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만 @@ -167,7 +166,7 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다. | CRD | 애그리게이트 API | | --------------------------- | -------------- | -| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | Go로 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. | +| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. | | 실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다. | 추가 서비스를 생성하면 실패할 수 있다. | | CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다. | 업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다. | | 여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다. | 인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다. | From f5981bc701da4150a11d6db574b0d25eda295c26 Mon Sep 17 00:00:00 2001 From: June Yi Date: Mon, 11 Oct 2021 18:08:14 +0900 Subject: [PATCH 09/43] [ko] Update scheduling-eviction refs #30000 task M19, M20 --- .../resource-bin-packing.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index 1ac3b81262..c3dcf84727 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -93,9 +93,9 @@ shape: ``` yaml resources: - - name: CPU + - name: cpu weight: 1 - - name: Memory + - name: memory weight: 1 ``` @@ -105,9 +105,9 @@ resources: resources: - name: intel.com/foo weight: 5 - - name: CPU + - name: cpu weight: 3 - - name: Memory + - name: memory weight: 1 ``` @@ -124,16 +124,16 @@ resources: ``` intel.com/foo : 2 -Memory: 256MB -CPU: 2 +memory: 256MB +cpu: 2 ``` 리소스의 가중치는 다음과 같다. ``` intel.com/foo : 5 -Memory: 1 -CPU: 3 +memory: 1 +cpu: 3 ``` FunctionShapePoint {{0, 0}, {100, 10}} @@ -143,13 +143,13 @@ FunctionShapePoint {{0, 0}, {100, 10}} ``` Available: intel.com/foo: 4 - Memory: 1 GB - CPU: 8 + memory: 1 GB + cpu: 8 Used: intel.com/foo: 1 - Memory: 256MB - CPU: 1 + memory: 256MB + cpu: 1 ``` 노드 점수는 다음과 같다. @@ -159,16 +159,16 @@ intel.com/foo = resourceScoringFunction((2+1),4) = (100 - ((4-3)*100/4) = (100 - 25) = 75 # requested + used = 75% * available - = rawScoringFunction(75) - = 7 # floor(75/10) + = rawScoringFunction(75) + = 7 # floor(75/10) -Memory = resourceScoringFunction((256+256),1024) +memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 # requested + used = 50% * available = rawScoringFunction(50) = 5 # floor(50/10) -CPU = resourceScoringFunction((2+1),8) +cpu = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) @@ -183,12 +183,12 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) ``` Available: intel.com/foo: 8 - Memory: 1GB - CPU: 8 + memory: 1GB + cpu: 8 Used: intel.com/foo: 2 - Memory: 512MB - CPU: 6 + memory: 512MB + cpu: 6 ``` 노드 점수는 다음과 같다. @@ -207,7 +207,7 @@ Memory = resourceScoringFunction((256+512),1024) = rawScoringFunction(75) = 7 -CPU = resourceScoringFunction((2+6),8) +cpu = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) From 893b9827198322689ae7ac4de03a54bab605c8ce Mon Sep 17 00:00:00 2001 From: Juhee Kang Date: Sun, 10 Oct 2021 14:03:11 +0900 Subject: [PATCH 10/43] [ko] Translate docs/reference/glossary/sysctl.md in Korean --- content/ko/docs/reference/glossary/sysctl.md | 23 ++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 content/ko/docs/reference/glossary/sysctl.md diff --git a/content/ko/docs/reference/glossary/sysctl.md b/content/ko/docs/reference/glossary/sysctl.md new file mode 100644 index 0000000000..bce4d26ba1 --- /dev/null +++ b/content/ko/docs/reference/glossary/sysctl.md @@ -0,0 +1,23 @@ +--- +title: sysctl +id: sysctl +date: 2019-02-12 +full_link: /docs/tasks/administer-cluster/sysctl-cluster/ +short_description: > + 유닉스 커널 파라미터를 가져오거나 설정하는 데 사용하는 인터페이스 + +aka: +tags: +- tool +--- + `sysctl`은 동작 중인 유닉스 커널의 속성을 읽거나 수정하는 데 사용하는 + (준)표준 인터페이스이다. + + + +유닉스 계열 시스템에서 `sysctl`은 관리자가 이러한 설정을 확인하고 수정하는데 사용하는 도구의 +이름이기도 하고, 해당 도구가 사용하는 시스템 콜이기도 +하다. + +{{< glossary_tooltip text="컨테이너" term_id="container" >}} 런타임과 +네트워크 플러그인은 특정 방식으로 설정된 `sysctl` 값에 의존성이 있을 수 있다. From 43508d68fc66794dea7ee86bf4ea01f25db5e0b3 Mon Sep 17 00:00:00 2001 From: June Yi Date: Mon, 11 Oct 2021 13:43:29 +0900 Subject: [PATCH 11/43] [ko] Update extend-kubernetes refs #30000 (Tasks: M14, M15, M16) note: M16 is not needed to be updated in Korean Co-authored-by: Juhee Kang --- content/ko/docs/concepts/extend-kubernetes/operator.md | 1 + content/ko/docs/concepts/extend-kubernetes/service-catalog.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 80ed86c2ec..d3ac7a4212 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -114,6 +114,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 * [Charmed Operator Framework](https://juju.is/) * [kubebuilder](https://book.kubebuilder.io/) 사용하기 +* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK) * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를 사용하여 직접 구현하기 diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index cc387c2f02..8d1cb3ee05 100644 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -32,7 +32,7 @@ weight: 40 서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다. -스토리지에 etcd를 사용하여 확장 API 서버와 컨트롤러로 구현된다. 또한 쿠버네티스 1.7 이상에서 제공하는 [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하여 API를 제공한다. +이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다.
From e616b0a519b1eb486dc0573780d4d6003d3f8878 Mon Sep 17 00:00:00 2001 From: lifeoncloud Date: Mon, 11 Oct 2021 21:29:33 +0900 Subject: [PATCH 12/43] Update 2021-08-04-kubernetes-release-1.22.md update date in Upcoming release webinar --- content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md b/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md index d936d7c767..d6df46ac55 100644 --- a/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md +++ b/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md @@ -142,7 +142,7 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에 # 다가오는 릴리스 웨비나 -이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 9월 7일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요. +이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 10월 5일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요. # 참여하기 From fe2ab336f60fcc6814e28530f7fe403b9a02615b Mon Sep 17 00:00:00 2001 From: seokho-son Date: Tue, 12 Oct 2021 22:28:49 +0900 Subject: [PATCH 13/43] Update outdated Korean in web-ui-dashboard.md --- .../web-ui-dashboard.md | 44 +++++++++++-------- 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index 7cb694386d..daa1417ce9 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -2,8 +2,9 @@ - -title: 웹 UI (대시보드) +title: 쿠버네티스 대시보드를 배포하고 접속하기 +description: >- + 웹 UI(쿠버네티스 대시보드)를 배포하고 접속한다. content_type: concept weight: 10 card: @@ -31,36 +32,39 @@ card: ## 대시보드 UI 배포 -대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다. +대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. -현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. +현재, 대시보드는 Bearer 토큰으로 로그인하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다. {{< warning >}} -시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다. +시연 중 생성한 샘플의 사용자에게는 관리자(admin) 권한이 부여되며, 이는 교육 목적으로만 사용한다. {{< /warning >}} ### 커맨드 라인 프록시 -kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드를 사용할 수 있다. + +`kubectl` 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드로의 +접속을 활성화할 수 있다. ``` kubectl proxy ``` -kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)에 대시보드를 사용하는 것을 가능하게 해줄 것이다. +kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)를 통해 대시보드에 접속할 수 있게 해줄 것이다. -UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다. +UI는 _오직_ 커맨드가 실행된 머신에서만 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다. {{< note >}} -Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 인증서를 지원하지 않는다. +Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더 +또는 X.509 인증서를 **지원하지 않는다**. {{< /note >}} ## 웰컴 뷰 @@ -75,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 ## 컨테이너화 된 애플리케이션 배포 대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. -애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다. +애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML 또는 JSON _매니페스트(manifest)_ 파일을 업로드할 수 있다. 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다. @@ -186,13 +190,14 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 ### YAML 또는 JSON 파일 업로드 쿠버네티스는 선언적인 설정을 제공한다. -이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 -이용하여 YAML 또는 JSON 설정 파일에 저장한다. +이 방식에서는 모든 설정이 매니페스트(YAML 또는 JSON 설정 파일)에 저장된다. +매니페스트는 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 +사용한다. -배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, -애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. +배포 마법사를 통해 애플리케이션 세부 사항들을 지정하는 대신, 애플리케이션을 하나 이상의 매니페스트로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. ## 대시보드 사용 + 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다. ### 탐색 @@ -201,9 +206,10 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다. -대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다. +대시보드는 몇 가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다. #### 어드민 개요 + 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, @@ -212,7 +218,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 #### 워크로드 선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. -애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 +애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. @@ -230,9 +236,9 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 #### 스토리지 -스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다. +스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트볼륨클레임 리소스들을 보여준다. -#### 컨피그 맵과 시크릿 +#### 컨피그맵과 시크릿 {#config-maps-and-secrets} 클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다. From 920818b73ac9dfff2aac456913a970f1eb5dc2e9 Mon Sep 17 00:00:00 2001 From: seokho-son Date: Tue, 12 Oct 2021 23:17:27 +0900 Subject: [PATCH 14/43] Update outdated Korean for task m59-m60 --- .../docs/tasks/administer-cluster/access-cluster-api.md | 9 ++++----- .../tasks/administer-cluster/dns-custom-nameservers.md | 3 +++ 2 files changed, 7 insertions(+), 5 deletions(-) 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 41b2225549..329dcc8ed2 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -146,11 +146,10 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이 필요할 수 있다. -일부 클러스터에서, API 서버는 인증이 필요하지 않다. -로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은 -없다. [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)은 -클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 -고 가용성 지원과 충돌할 수 있다. +일부 클러스터에서, API 서버는 인증이 필요하지 않다. 로컬 호스트에서 제공되거나, +방화벽으로 보호될 수 있다. 이에 대한 표준은 없다. +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 클러스터 +관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 고 가용성 지원과 충돌할 수 있다. ### API에 프로그래밍 방식으로 접근 diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index 8d67bea2db..df79fe7790 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -1,4 +1,7 @@ --- + + + title: DNS 서비스 사용자 정의하기 content_type: task min-kubernetes-server-version: v1.12 From b8a764b84339f58588dad83542f43b2bf90ae1c2 Mon Sep 17 00:00:00 2001 From: June Yi Date: Mon, 11 Oct 2021 18:02:08 +0900 Subject: [PATCH 15/43] [ko] Update working-with-objects refs #30000 task M17, M18 Co-authored-by: Seokho Son --- .../overview/working-with-objects/kubernetes-objects.md | 9 ++++----- .../concepts/overview/working-with-objects/namespaces.md | 3 +++ 2 files changed, 7 insertions(+), 5 deletions(-) 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 cf1f5675bb..c090b171f4 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 @@ -81,12 +81,11 @@ deployment.apps/nginx-deployment created * `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터 * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지 -오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. -예를 들어, 파드에 대한 `spec` 포맷은 -[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) -에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 -[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. +오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. +예를 들어, API 내 파드에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 대한 레퍼런스에서, +디플로이먼트에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)에 대한 레퍼런스에서 확인할 수 있다. +해당 API 레퍼런스 페이지에서 PodSpec과 DeploymentSpec에 대해 언급된 내용을 볼 수 있다. 이 이름들은 쿠버네티스가 API를 구현하는데 사용한 Go 언어 코드 구현의 세부 내용이다. ## {{% heading "whatsnext" %}} 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 049b30a1f7..fb2e52534c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -59,6 +59,9 @@ kube-system Active 1d * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스 + * `kube-node-lease` 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) + 오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를 + 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다. ### 요청에 네임스페이스 설정하기 From c1d5cec4c30f23bb120c90f4d37f6a5d13c5aafa Mon Sep 17 00:00:00 2001 From: bang9211 Date: Mon, 18 Oct 2021 00:41:28 +0900 Subject: [PATCH 16/43] Translate tasks/run-application/force-delete-stateful-set-pod.md in Korean --- .../force-delete-stateful-set-pod.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md diff --git a/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md new file mode 100644 index 0000000000..5c9f1358a4 --- /dev/null +++ b/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -0,0 +1,96 @@ +--- + + + + + +title: 스테이트풀셋(StatefulSet) 파드 강제 삭제하기 +content_type: task +weight: 70 +--- + + + +이 페이지에서는 {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}의 일부인 파드를 삭제하는 방법을 보여주고 +이 과정에서 고려해야 할 사항을 설명한다. + + +## {{% heading "prerequisites" %}} + + +* 이것은 상당히 고급 태스크이며 스테이트풀셋 고유의 속성 중 일부를 위반할 가능성이 있다. +* 계속하기 전에 아래 나열된 고려 사항을 숙지하도록 한다. + + + + + +## 스테이트풀셋 고려 사항 + +정상적인 스테이트풀셋의 작동에서는 스테이트풀셋 파드를 강제로 삭제할 필요가 **절대** 없다. [스테이트풀셋 컨트롤러](/ko/docs/concepts/workloads/controllers/statefulset/)는 스테이트풀셋의 멤버 생성, 스케일링, 삭제를 담당한다. 서수 0부터 N-1까지 지정된 수의 파드가 활성 상태이고 준비되었는지 확인한다. 스테이트풀셋은 언제든지 클러스터에서 실행 중인 지정된 신원을 가진 최대 하나의 파드가 있는지 확인한다. 이를 스테이트풀셋에서 제공하는 *최대 하나* 의미론이라고 한다. + +수동 강제 삭제는 스테이트풀셋 고유의 최대 하나 의미론을 위반할 가능성이 있으므로 주의해서 수행해야 한다. 스테이트풀셋은 안정적인 네트워크 신원과 안정적인 스토리지가 필요한 분산 클러스터 애플리케이션을 실행하는 데 사용할 수 있다. 이러한 애플리케이션은 종종 고정된 신원을 가진 고정된 수의 구성원 앙상블에 의존하는 구성을 가진다. 여러 구성원이 동일한 신원을 갖는 것은 재앙이 될 수 있으며 데이터 손실로 이어질 수 있다(예: 쿼럼 기반 시스템의 스플릿 브레인(split-brain) 시나리오). + +## 파드 삭제 + +다음 명령을 사용하여 파드를 단계적으로 삭제할 수 있다. + +```shell +kubectl delete pods +``` + +위의 내용이 단계적인 종료로 이어지려면 파드가 +`pod.Spec.TerminationGracePeriodSeconds`를 0으로 지정하지 **않아야 한다**. +`pod.Spec.TerminationGracePeriodSeconds`를 0초로 설정하는 관행은 안전하지 않으며 +스테이트풀셋 파드에서 강력히 권장하지 않는다. 단계적 삭제는 안전하며 kubelet이 apiserver에서 이름을 삭제하기 전에 파드가 +[정상적으로 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)되도록 한다. + +노드에 연결할 수 없는 경우 파드는 자동으로 삭제되지 않는다. +연결할 수 없는 노드에서 실행 중인 파드는 [타임아웃](/ko/docs/concepts/architecture/nodes/#condition) 후에 +'Terminating'이나 'Unknown' 상태가 된다. + +사용자가 연결할 수 없는 노드에서 파드를 단계적으로 삭제하려고 하면 파드가 이러한 상태에 들어갈 수도 있다. +이러한 상태의 파드를 apiserver에서 제거할 수 있는 유일한 방법은 다음과 같다. + +* 노드 오브젝트가 삭제된다(사용자 또는 [노드 컨트롤러](/ko/docs/concepts/architecture/nodes/)에 의해). +* 응답하지 않는 노드의 kubelet이 응답을 시작하고 파드를 종료하여 apiserver에서 항목을 제거한다. +* 사용자가 파드를 강제로 삭제한다. + +권장되는 모범 사례는 첫 번째 또는 두 번째 방법을 사용하는 것이다. 노드가 죽은 것으로 확인되면(예: 네트워크에서 영구적으로 연결이 끊기거나 전원이 꺼진 경우 등) 노드 오브젝트를 삭제한다. 노드에 네트워크 파티션이 있는 경우 이를 해결하거나 해결될 때까지 기다린다. 파티션이 복구되면 kubelet은 파드 삭제를 완료하고 apiserver에서 해당 이름을 해제한다. + +일반적으로 시스템은 파드가 노드에서 더 이상 실행되지 않거나 노드가 관리자에 의해 삭제되면 삭제를 완료한다. 파드를 강제로 삭제하여 이를 재정의할 수 있다. + +### 강제 삭제 + +강제 삭제는 파드가 종료되었다는 kubelet의 확인을 기다리지 **않는다**. 강제 삭제가 파드를 죽이는 데 성공했는지 여부와 관계없이 즉시 apiserver에서 이름을 해제한다. 이렇게 하면 스테이트풀셋 컨트롤러가 동일한 신원으로 대체 파드를 생성할 수 있다. 이것은 여전히 실행 중인 파드와 중복될 수 있으며, 해당 파드가 여전히 스테이트풀셋의 다른 멤버와 통신할 수 있다면 스테이트풀셋이 보장하도록 설계된 최대 하나 의미론을 위반할 것이다. + +스테이트풀셋 파드를 강제로 삭제하는 것은 문제의 파드가 스테이트풀셋의 다른 파드와 다시는 접촉하지 않으며 대체 생성을 위해 해당 이름을 안전하게 해제할 수 있다고 주장하는 것이다. + +kubectl 버전 >= 1.5를 사용하여 파드를 강제로 삭제하려면, 다음을 수행한다. + +```shell +kubectl delete pods --grace-period=0 --force +``` + +kubectl <= 1.4 버전을 사용하는 경우, `--force` 옵션을 생략하고 다음을 사용해야 한다. + +```shell +kubectl delete pods --grace-period=0 +``` + +이러한 명령 후에도 파드가 `Unknown` 상태에서 멈추면, 다음 명령을 사용하여 클러스터에서 파드를 제거한다. + +```shell +kubectl patch pod -p '{"metadata":{"finalizers":null}}' +``` + +항상 관련된 위험에 대해 완전히 이해한 상태에서 주의 깊게 스테이트풀셋 파드의 강제 삭제를 수행한다. + + + +## {{% heading "whatsnext" %}} + + +[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기. + + From ae291c71d6b8d71d71fd0adfcca420c5cc73807f Mon Sep 17 00:00:00 2001 From: June Yi Date: Fri, 22 Oct 2021 00:19:27 +0900 Subject: [PATCH 17/43] [ko] Update `concepts/architecture/nodes.md` refs #30000 task M2 --- .../ko/docs/concepts/architecture/nodes.md | 108 ++++++++++-------- 1 file changed, 61 insertions(+), 47 deletions(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 5daed12077..5ceb5d98ce 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -122,6 +122,9 @@ kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다. kubectl cordon $NODENAME ``` +보다 자세한 내용은 [안전하게 노드를 드레인(drain)하기](/docs/tasks/administer-cluster/safely-drain-node/) +를 참고한다. + {{< note >}} {{< glossary_tooltip term_id="daemonset" >}}에 포함되는 일부 파드는 스케줄 불가 노드에서 실행될 수 있다. 일반적으로 데몬셋은 워크로드 애플리케이션을 @@ -174,7 +177,7 @@ kubectl describe node 대신 코드화된 노드는 사양에 스케줄 불가로 표시된다. {{< /note >}} -노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다. +쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다. ```json "conditions": [ @@ -189,20 +192,30 @@ kubectl describe node ] ``` -ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. +ready 컨디션의 `status`가 `pod-eviction-timeout` +({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" +>}}에 전달된 인수)보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, +[노드 컨트롤러](#node-controller)가 해당 노드에 할당된 전체 파드에 대해 +{{< glossary_tooltip text="API를 이용한 축출" term_id="api-eviction" >}} +을 트리거한다. 기본 축출 타임아웃 기간은 +**5분** 이다. +노드에 접근이 불가할 때와 같은 경우, API 서버는 노드 상의 kubelet과 통신이 불가하다. +API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. +그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. -노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 -강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 +노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. +파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 -apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. +API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. -노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 +노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는 [테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. -또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다. +또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 +{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다. 자세한 내용은 [컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다. @@ -222,8 +235,34 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 ### 정보 -커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다. -이 정보는 Kubelet에 의해 노드로부터 수집된다. +커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다. + +이 정보는 Kubelet이 노드로부터 수집해서 쿠버네티스 API로 이를 보낸다. + +## 하트비트 + +쿠버네티스 노드가 보내는 하트비트는 클러스터가 개별 노드가 가용한지를 +판단할 수 있도록 도움을 주고, 장애가 발견된 경우 조치를 할 수 있게한다. + +노드에는 두 가지 형태의 하트비트가 있다. + +* 노드의 `.status`에 대한 업데이트 +* `kube-node-lease` + {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트. + 각 노드는 연관된 리스 오브젝트를 갖는다. + +노드의 `.status`와 비교해서, 리스는 경량의 리소스이다. +큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 필요한 성능 영향도를 줄일 수 있다. + +kubelet은 노드의 `.status` 생성과 업데이트 및 +관련된 리스의 업데이트를 담당한다. + +- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다. + 노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다. +- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다. + 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다. + 만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다. + ### 노드 컨트롤러 @@ -241,39 +280,15 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 다음을 담당한다. -- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가 - 하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady - 컨디션을 ConditionUnknown으로 업데이트 한다. -- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다. - ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, - 파드를 축출하기 시작하는 값은 5분이다. +- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다. + 이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다. +- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서 + [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다. + 기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다. 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. -#### 하트비트 - -쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다. - -하트비트의 두 가지 형태는 `NodeStatus` 와 -[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)이다. -각 노드에는 `kube-node-lease` 라는 -{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다. -리스는 경량 리소스로, 클러스터가 확장될 때 -노드의 하트비트 성능을 향상 시킨다. - -kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 -의무가 있다. - -- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우, - `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트 - 주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초 - 보다 훨씬 길다. -- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기). - 리스 업데이트는 `NodeStatus` 업데이트와는 - 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 - 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다. - -#### 안정성 +#### 축출 빈도 한계 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여 @@ -281,8 +296,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 -체크한다(NodeReady 컨디션은 ConditionUnknown 또는 -ConditionFalse 다). +체크한다(NodeReady 컨디션은 `ConditionUnknown` 또는 +`ConditionFalse` 다). - 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold` (기본값 0.55)가 되면 축출 속도가 감소한다. - 클러스터가 작으면 (즉 `--large-cluster-size-threshold` @@ -292,16 +307,15 @@ ConditionFalse 다). 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. -만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, -오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다. +만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상, +축출 매커니즘은 영역 별 가용성을 고려하지 않는다. 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 `--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이 -완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. -이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 -복원될 때까지 모든 축출을 중지하는 것으로 여긴다. +완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다. +이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.) 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의 노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다. @@ -309,7 +323,7 @@ ConditionFalse 다). {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. -### 노드 용량 +## 리소스 용량 추적 {#node-capacity} 노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의 양과 CPU의 수를 추적한다. From c1a024808a8a5027679ef8fe1ea0aaada29035c8 Mon Sep 17 00:00:00 2001 From: June Yi Date: Sat, 23 Oct 2021 08:35:28 +0900 Subject: [PATCH 18/43] [ko] Update content/ko/docs/concepts/services-networking/ingress.md refs #30192 --- content/ko/docs/concepts/services-networking/ingress.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 805260d159..e9e5f12a05 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -164,8 +164,8 @@ Events: 요청은 _p_ 경로에 일치한다. {{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막 - 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 - `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}} + 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 는 + `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 와는 일치하지 않는다). {{< /note >}} ### 예제 From 3a0844cdf0e6680a7d9404591efc93b2636e71e8 Mon Sep 17 00:00:00 2001 From: June Yi Date: Sat, 23 Oct 2021 08:51:16 +0900 Subject: [PATCH 19/43] [ko] Update `content/ko/docs/concepts/security` refs #30000 task M21 and M22 --- content/ko/docs/concepts/security/controlling-access.md | 2 +- content/ko/docs/concepts/security/overview.md | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index 9612159eb4..cf2fc529ce 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -139,7 +139,7 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 - 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소 (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다. - TLS가 없다. - - 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다. + - 기본 포트는 8080이다. - 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다. - 요청이 인증 및 인가 모듈을 **우회한다**. - 요청이 어드미션 제어 모듈(들)에 의해 처리된다. diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 47d0548a7e..dd81fe6b2c 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -60,6 +60,7 @@ Amazon Web Services | https://aws.amazon.com/security/ | Google Cloud Platform | https://cloud.google.com/security/ | 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 | {{< /table >}} From da17eafbd355b74b4f802de7392c441b8360d5d2 Mon Sep 17 00:00:00 2001 From: June Yi Date: Sat, 23 Oct 2021 15:54:46 +0900 Subject: [PATCH 20/43] [ko] Update content/ko/docs/concepts/storage refs #30000 task M27 and M28 Note: There's nothing to do for M28(`concepts/storage/volumes.md`). --- .../concepts/storage/persistent-volumes.md | 39 ++++++++++++------- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 87d43ae09e..4bc8926e3b 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -130,8 +130,10 @@ Events: `Retain` 반환 정책은 리소스를 수동으로 반환할 수 있게 한다. 퍼시스턴트볼륨클레임이 삭제되면 퍼시스턴트볼륨은 여전히 존재하며 볼륨은 "릴리스 된" 것으로 간주된다. 그러나 이전 요청자의 데이터가 여전히 볼륨에 남아 있기 때문에 다른 요청에 대해서는 아직 사용할 수 없다. 관리자는 다음 단계에 따라 볼륨을 수동으로 반환할 수 있다. 1. 퍼시스턴트볼륨을 삭제한다. PV가 삭제된 후에도 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산이 존재한다. -1. 관련 스토리지 자산의 데이터를 수동으로 삭제한다. -1. 연결된 스토리지 자산을 수동으로 삭제하거나 동일한 스토리지 자산을 재사용하려는 경우 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다. +2. 관련 스토리지 자산의 데이터를 수동으로 삭제한다. +3. 연결된 스토리지 자산을 수동으로 삭제한다. + +동일한 스토리지 자산을 재사용하려는 경우, 동일한 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다. #### Delete(삭제) @@ -412,11 +414,19 @@ spec: 접근 모드는 다음과 같다. -* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다 -* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다 -* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다 -* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다. - 쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다. +`ReadWriteOnce` +: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. + +`ReadWriteMany` +: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. + +`ReadWriteOncePod` +: 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다. + + + +[퍼시스턴트 볼륨에 대한 단일 파드 접근 모드 소개](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/) 블로그 기사에서 이에 대해 보다 자세한 내용을 다룬다. + CLI에서 접근 모드는 다음과 같이 약어로 표시된다. @@ -509,7 +519,7 @@ PV는 `storageClassName` 속성을 대부분의 볼륨 유형의 경우 이 필드를 설정할 필요가 없다. [AWS EBS](/ko/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) 및 [Azure Disk](/ko/docs/concepts/storage/volumes/#azuredisk) 볼륨 블록 유형에 자동으로 채워진다. [로컬](/ko/docs/concepts/storage/volumes/#local) 볼륨에 대해서는 이를 명시적으로 설정해야 한다. {{< /note >}} -PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다. +PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다. 노드 어피니티를 명기하기 위해서는, PV의 `.spec`에 `nodeAffinity`를 설정한다. [퍼시스턴트볼륨](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) API 레퍼런스에 해당 필드에 대해 보다 자세한 내용이 있다. ### 단계(Phase) @@ -897,16 +907,15 @@ PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, 클러스터에 스토리지 시스템이 없음을 나타낸다(이 경우 사용자는 PVC가 필요한 구성을 배포할 수 없음). - ## {{% heading "whatsnext" %}} - +## {{% heading "whatsnext" %}} * [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기 * [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기 -### 참고 +### API 레퍼런스 {#reference} -* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) -* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) -* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) -* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) +본 페이지에 기술된 API에 대해서 다음을 읽어본다. + +* [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/) +* [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/) From fa02dd9e77e2e7e3f16f6ef72886ccd386a6b5c1 Mon Sep 17 00:00:00 2001 From: jmyung Date: Mon, 11 Oct 2021 02:44:36 +0900 Subject: [PATCH 21/43] Translate content\en\docs\tasks\configure-pod-container\configure-gmsa.md in Korean --- .../configure-pod-container/configure-gmsa.md | 310 ++++++++++++++++++ 1 file changed, 310 insertions(+) create mode 100644 content/ko/docs/tasks/configure-pod-container/configure-gmsa.md diff --git a/content/ko/docs/tasks/configure-pod-container/configure-gmsa.md b/content/ko/docs/tasks/configure-pod-container/configure-gmsa.md new file mode 100644 index 0000000000..cd95030383 --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/configure-gmsa.md @@ -0,0 +1,310 @@ +--- +title: 윈도우 파드와 컨테이너용 GMSA 구성 +content_type: task +weight: 20 +--- + + + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +이 페이지는 윈도우 노드에서 실행되는 파드와 컨테이너용으로 [그룹 관리 서비스 어카운트(Group Managed Service Accounts,](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) GMSA)를 구성하는 방법을 소개한다. 그룹 관리 서비스 어카운트는 자동 암호 관리, 단순화된 서비스 사용자 이름(service principal name, SPN) 관리, 여러 서버에 걸쳐 다른 관리자에게 관리를 위임하는 기능을 제공하는 특정한 유형의 액티브 디렉터리(Active Directory) 계정이다. + +쿠버네티스에서 GMSA 자격 증명 사양은 쿠버네티스 클러스터 전체 범위에서 사용자 정의 리소스(Custom Resources)로 구성된다. 윈도우 파드 및 파드 내의 개별 컨테이너들은 다른 윈도우 서비스와 상호 작용할 때 도메인 기반 기능(예: Kerberos 인증)에 GMSA를 사용하도록 구성할 수 있다. v1.16부터 도커 런타임은 윈도우 워크로드용 GMSA를 지원한다. + + + +## {{% heading "prerequisites" %}} + +쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 `kubectl` 커맨드라인 툴을 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 한다. 이 섹션에서는 각 클러스터에 대해 한 번씩 필요한 일련의 초기 단계를 다룬다. + + +### GMSACredentialSpec CRD 설치 +GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(CustomResourceDefinition,](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) CRD)을 클러스터에서 구성하여 사용자 정의 리소스 유형 `GMSACredentialSpec`을 정의해야 한다. GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)을 다운로드하고 gmsa-crd.yaml로 저장한다. +다음, `kubectl apply -f gmsa-crd.yaml` 로 CRD를 설치한다. + +### GMSA 사용자를 검증하기 위해 웹훅 설치 +쿠버네티스 클러스터에서 두 개의 웹훅을 구성하여 파드 또는 컨테이너 수준에서 GMSA 자격 증명 사양 참조를 채우고 검증한다. + +1. 변형(mutating) 웹훅은 (파드 사양의 이름별로) GMSA에 대한 참조를 파드 사양 내 JSON 형식의 전체 자격 증명 사양으로 확장한다. + +1. 검증(validating) 웹훅은 GMSA에 대한 모든 참조가 파드 서비스 어카운트에서 사용하도록 승인되었는지 확인한다. + +위의 웹훅 및 관련 오브젝트를 설치하려면 다음 단계가 필요하다. + +1. 인증서 키 쌍 생성 (웹훅 컨테이너가 클러스터와 통신할 수 있도록 하는데 사용됨) + +1. 위의 인증서로 시크릿을 설치 + +1. 핵심 웹훅 로직에 대한 디플로이먼트(deployment)를 생성 + +1. 디플로이먼트를 참조하여 검증 및 변경 웹훅 구성을 생성 + +[스크립트](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh)를 사용하여 GMSA 웹훅과 위에서 언급한 관련 오브젝트를 배포 및 구성할 수 있다. 스크립트는 ```--dry-run=server``` 옵션으로 실행되어 클러스터에 대한 변경 사항을 검토할 수 있다. + +스크립트에서 사용하는 [YAML 템플릿](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)을 사용하여 웹훅 및 (파라미터를 적절히 대체하여) 관련 오브젝트를 수동으로 배포할 수도 있다. + + + + + +## 액티브 디렉터리에서 GMSA 및 윈도우 노드 구성 +쿠버네티스의 파드가 GMSA를 사용하도록 구성되기 전에 [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)에 설명된 대로 액티브 디렉터리에서 원하는 GMSA를 프로비저닝해야 한다. [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)에 설명된 대로 원하는 GMSA와 연결된 시크릿 자격 증명에 접근하려면 (쿠버네티스 클러스터의 일부인) 윈도우 워커 노드를 액티브 디렉터리에서 구성해야 한다. + +## GMSA 자격 증명 사양 리소스 생성 +(앞에서 설명한 대로) GMSACredentialSpec CRD를 설치하면 GMSA 자격 증명 사양이 포함된 사용자 정의 리소스를 구성할 수 있다. GMSA 자격 증명 사양에는 시크릿 또는 민감한 데이터가 포함되어 있지 않다. 이것은 컨테이너 런타임이 원하는 윈도우 컨테이너 GMSA를 설명하는 데 사용할 수 있는 정보이다. GMSA 자격 증명 사양은 [PowerShell 스크립트](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 유틸리티를 사용하여 YAML 형식으로 생성할 수 있다. + +다음은 JSON 형식으로 GMSA 자격 증명 사양 YAML을 수동으로 생성한 다음 변환하는 단계이다. + +1. CredentialSpec [모듈](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1) 가져오기(import): `ipmo CredentialSpec.psm1` + +1. `New-CredentialSpec`을 사용하여 JSON 형식의 자격 증명 사양을 만든다. WebApp1이라는 GMSA 자격 증명 사양을 만들려면 `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`를 호출한다. + +1. `Get-CredentialSpec`을 사용하여 JSON 파일의 경로를 표시한다. + +1. credspec 파일을 JSON에서 YAML 형식으로 변환하고 필요한 헤더 필드 `apiVersion`, `kind`, `metadata`, `credspec`을 적용하여 쿠버네티스에서 구성할 수 있는 GMSACredentialSpec 사용자 정의 리소스로 만든다. + +다음 YAML 구성은 `gmsa-WebApp1`이라는 GMSA 자격 증명 사양을 설명한다. + +```yaml +apiVersion: windows.k8s.io/v1alpha1 +kind: GMSACredentialSpec +metadata: + name: gmsa-WebApp1 #임의의 이름이지만 참조로 사용된다. +credspec: + ActiveDirectoryConfig: + GroupManagedServiceAccounts: + - Name: WebApp1 #GMSA 계정의 사용자 이름 + Scope: CONTOSO #NETBIOS 도메인 명 + - Name: WebApp1 #GMSA 계정의 사용자 이름 + Scope: contoso.com #DNS 도메인 명 + CmsPlugins: + - ActiveDirectory + DomainJoinConfig: + DnsName: contoso.com #DNS 도메인 명 + DnsTreeName: contoso.com #DNS 도메인 명 루트 + Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a #GUID + MachineAccountName: WebApp1 #GMSA 계정의 사용자 이름 + NetBiosName: CONTOSO #NETBIOS 도메인 명 + Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA +``` + +위의 자격 증명 사양 리소스는 `gmsa-Webapp1-credspec.yaml`로 저장되고 `kubectl apply -f gmsa-Webapp1-credspec.yml`을 사용하여 클러스터에 적용될 수 있다. + +## 특정 GMSA 자격 증명 사양에서 RBAC를 활성화하도록 cluster role 구성 +각 GMSA 자격 증명 사양 리소스에 대해 cluster role을 정의해야 한다. 이것은 일반적으로 서비스 어카운트인 주체에 의해 특정 GMSA 리소스에 대한 `use` 동사를 승인한다. 다음 예는 위에서 `gmsa-WebApp1` 자격 증명 사양의 사용을 승인하는 클러스터 롤(cluster role)을 보여준다. 파일을 gmsa-webapp1-role.yaml로 저장하고 `kubectl apply -f gmsa-webapp1-role.yaml`을 사용하여 적용한다. + +```yaml +#credspec을 읽을 Role 생성 +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: webapp1-role +rules: +- apiGroups: ["windows.k8s.io"] + resources: ["gmsacredentialspecs"] + verbs: ["use"] + resourceNames: ["gmsa-WebApp1"] +``` + +## 특정 GMSA credspecs를 사용하도록 서비스 어카운트에 롤 할당 +(파드가 사용하게 되는) 서비스 어카운트는 위에서 생성한 클러스터 롤에 바인딩되어야 한다. 이렇게 하면 서비스 어카운트가 원하는 GMSA 자격 증명 사양 리소스를 사용할 수 있다. 다음은 위에서 생성한 `gmsa-WebApp1` 자격 증명 사양 리소스를 사용하기 위해 `webapp1-role` 클러스터 롤에 바인딩되는 기본(default) 서비스 어카운트이다. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: allow-default-svc-account-read-on-gmsa-WebApp1 + namespace: default +subjects: +- kind: ServiceAccount + name: default + namespace: default +roleRef: + kind: ClusterRole + name: webapp1-role + apiGroup: rbac.authorization.k8s.io +``` + +## 파드 사양에서 GMSA 자격 증명 사양 참조 구성 +파드 사양 필드 `securityContext.windowsOptions.gmsaCredentialSpecName`은 파드 사양에서 원하는 GMSA 자격 증명 사양 사용자 정의 리소스에 대한 참조를 지정하는 데 사용된다. 이렇게 하면 지정된 GMSA를 사용하도록 파드 사양의 모든 컨테이너가 구성된다. 다음은 `gmsa-WebApp1`을 참조하도록 채워진 어노테이션이 있는 샘플 파드 사양이다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + run: with-creds + name: with-creds + namespace: default +spec: + replicas: 1 + selector: + matchLabels: + run: with-creds + template: + metadata: + labels: + run: with-creds + spec: + securityContext: + windowsOptions: + gmsaCredentialSpecName: gmsa-webapp1 + containers: + - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 + imagePullPolicy: Always + name: iis + nodeSelector: + kubernetes.io/os: windows +``` + +파드 사양의 개별 컨테이너는 컨테이너별 `securityContext.windowsOptions.gmsaCredentialSpecName` 필드를 사용하여 원하는 GMSA credspec을 지정할 수도 있다. 다음은 예이다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + run: with-creds + name: with-creds + namespace: default +spec: + replicas: 1 + selector: + matchLabels: + run: with-creds + template: + metadata: + labels: + run: with-creds + spec: + containers: + - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 + imagePullPolicy: Always + name: iis + securityContext: + windowsOptions: + gmsaCredentialSpecName: gmsa-Webapp1 + nodeSelector: + kubernetes.io/os: windows +``` + +(위에서 설명한 대로) GMSA 필드가 채워진 파드 사양이 클러스터에 적용되면 다음과 같은 일련의 이벤트가 발생한다. + +1. 변형 웹훅은 GMSA 자격 증명 사양 리소스에 대한 모든 참조를 확인하고 GMSA 자격 증명 사양의 내용으로 확장한다. + +1. 검증 웹훅은 파드와 연결된 서비스 어카운트가 지정된 GMSA 자격 증명 사양의 `use` 동사에 대해 승인되었는지 확인한다. + +1. 컨테이너 런타임은 컨테이너가 액티브 디렉터리에서 GMSA의 ID를 가정하고 해당 ID를 사용하여 도메인의 서비스에 접근할 수 있도록 지정된 GMSA 자격 증명 사양으로 각 윈도우 컨테이너를 구성한다. + +## Containerd + +윈도우 서버 2019에서 containerd와 함께 GMSA를 사용하려면 패치 [KB5000822](https://support.microsoft.com/ko-kr/topic/2021년-3월-9일-kb5000822-os-빌드-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564)된 OS Build 17763.1817 (또는 이후 버전)을 실행해야 한다. + +또한 파드에서 SMB 공유에 연결하려고 할 때 발생하는 containerd와 관련된 알려진 문제가 있다. GMSA를 구성하면 파드가 hostname 또는 FQDN을 사용하여 공유에 연결할 수 없지만, IP 주소를 사용하여 공유에 연결하면 예상대로 작동한다. + +```PowerShell +ping adserver.ad.local +``` +hostname을 IPv4 주소로 올바르게 변환한다. 출력은 다음과 유사하다. + +``` +Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data: +Reply from 192.168.111.18: bytes=32 time=6ms TTL=124 +Reply from 192.168.111.18: bytes=32 time=5ms TTL=124 +Reply from 192.168.111.18: bytes=32 time=5ms TTL=124 +Reply from 192.168.111.18: bytes=32 time=5ms TTL=124 +``` + +그러나 hostname을 사용하여 디렉터리를 탐색하려고 할 때 + +```PowerShell +cd \\adserver.ad.local\test +``` + +대상 공유가 존재하지 않음을 암시하는 오류가 표시된다. + +``` +cd : Cannot find path '\\adserver.ad.local\test' because it does not exist. +At line:1 char:1 ++ cd \\adserver.ad.local\test ++ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException + + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand +``` + +그러나 IPv4 주소를 대신 사용하여 공유를 탐색하면 오류가 사라진다. 다음은 예시이다. + +```PowerShell +cd \\192.168.111.18\test +``` + +공유 내의 디렉터리로 변경하면 다음과 유사한 프롬프트가 표시된다. + +``` +Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test> +``` + +동작을 수정하려면 노드에서 `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1`을 실행하여 필요한 레지스트리 키를 추가해야 한다. 이 노드 변경 사항은 새로 생성된 파드에만 적용되는데, SMB 공유에 액세스해야 하는 실행 중인 파드를 다시 생성해야 하는 것을 의미한다. + +## 문제 해결 + +GMSA가 사용자 환경에서 작동하도록 하는 데 어려움이 있는 경우 취할 수 있는 몇 가지 문제 해결 단계가 있다. + +먼저 credspec이 파드에 전달되었는지 확인한다. 이렇게 하려면 파드 중 하나에서 `exec`를 실행하고 `nltest.exe /parentdomain` 명령의 출력을 확인해야 한다. + +아래 예에서 파드는 credspec을 올바르게 가져오지 못했다. + +```PowerShell +kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe +``` +`nltest.exe /parentdomain` 는 다음과 같은 오류를 발생시킨다. +``` +Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE +``` + +파드가 credspec을 올바르게 가져오면 다음으로 도메인과의 통신을 확인한다. 먼저 파드 내부에서 nslookup을 빠르게 수행하여 도메인의 루트를 찾는다. + +이것은 다음의 세 가지를 의미한다. + +1. 파드는 DC에 도달할 수 있다. +1. DC는 파드에 도달할 수 있다. +1. DNS가 올바르게 작동하고 있다. + +DNS 및 통신 테스트를 통과하면 다음으로 파드가 도메인과 보안 채널 통신을 설정했는지 확인해야 한다. 이렇게 하려면 파드에서 다시 `exec`를 실행하고 `nltest.exe /query` 명령을 실행한다. + +```PowerShell +nltest.exe /query +``` + +결과는 다음과 같다. +``` +I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE +``` + +이것은 어떤 이유로 파드가 credspec에 지정된 계정을 사용하여 도메인에 로그온할 수 없음을 알려준다. 다음을 실행하여 보안 채널 복구를 시도할 수 있다. + +```PowerShell +nltest /sc_reset:domain.example +``` + +명령이 성공하면 다음과 유사한 출력이 표시된다. +``` +Flags: 30 HAS_IP HAS_TIMESERV +Trusted DC Name \\dc10.domain.example +Trusted DC Connection Status Status = 0 0x0 NERR_Success +The command completed successfully +``` + +위의 방법으로 오류가 수정되면 다음 수명 주기 훅(hook)을 파드 사양에 추가하여 단계를 자동화할 수 있다. 오류가 수정되지 않은 경우 credspec을 다시 검사하여 정확하고 완전한지 확인해야 한다. + +```yaml + image: registry.domain.example/iis-auth:1809v1 + lifecycle: + postStart: + exec: + command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"] + imagePullPolicy: IfNotPresent +``` + +위의 `lifecycle` 섹션을 파드 사양에 추가하면, 파드는 `nltest.exe /query` 명령이 오류 없이 종료될 때까지 나열된 명령을 실행하여 `netlogon` 서비스를 다시 시작한다. From ccd10a4e08fda0531eb909c29d23e0be144c0439 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Tue, 26 Oct 2021 04:56:47 +0900 Subject: [PATCH 22/43] Update ko/kubeadm-upgrade --- .../kubeadm/kubeadm-upgrade.md | 81 +++++++++---------- 1 file changed, 40 insertions(+), 41 deletions(-) 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 c009339acc..0e76e46c93 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -9,17 +9,17 @@ weight: 20 이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를 -{{< skew latestVersionAddMinor -1 >}}.x 버전에서 {{< skew latestVersion >}}.x 버전으로, -{{< skew latestVersion >}}.x 버전에서 {{< skew latestVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우 +{{< skew currentVersionAddMinor -1 >}}.x 버전에서 {{< skew currentVersion >}}.x 버전으로, +{{< skew currentVersion >}}.x 버전에서 {{< skew currentVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우 마이너 버전을 건너뛴다. 이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면, 이 페이지 대신 다음의 페이지들을 참고한다. -- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -2 >}}에서 {{< skew latestVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -3 >}}에서 {{< skew latestVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -4 >}}에서 {{< skew latestVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -5 >}}에서 {{< skew latestVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) 추상적인 업그레이드 작업 절차는 다음과 같다. @@ -45,19 +45,19 @@ weight: 20 ## 업그레이드할 버전 결정 -OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVersion >}})을 찾는다. +OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리스 버전({{< skew currentVersion >}})을 찾는다. {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} apt update apt-cache madison kubeadm - # 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다 - # {{< skew latestVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다. + # 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다 + # {{< skew currentVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다. {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다 - # {{< skew latestVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다. + # 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다 + # {{< skew currentVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다. {{% /tab %}} {{< /tabs >}} @@ -74,20 +74,21 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe {{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # {{< skew latestVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다. + # {{< skew currentVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다. apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. - yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} +
- 다운로드하려는 버전이 잘 받아졌는지 확인한다. @@ -120,13 +121,13 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe ```shell # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다. - sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x + sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x ``` 명령이 완료되면 다음을 확인해야 한다. ``` - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy! + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` @@ -169,25 +170,22 @@ sudo kubeadm upgrade apply - 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. {{< tabs name="k8s_install_kubelet" >}} -{{< tab name="Ubuntu, Debian 또는 HypriotOS" >}} - 
>
-    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
+{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
+    # replace x in {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
-
-{{< /tab >}} -{{< tab name="CentOS, RHEL 또는 Fedora" >}} - 
-    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
-
-{{< /tab >}} + apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 +{{% /tab %}} +{{% tab name="CentOS, RHEL 또는 Fedora" %}} + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes +{{% /tab %}} {{< /tabs >}} +
- kubelet을 다시 시작한다. @@ -216,18 +214,18 @@ sudo systemctl restart kubelet {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 + # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -254,20 +252,21 @@ sudo systemctl restart kubelet {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 + # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} +
- kubelet을 다시 시작한다. From 50b47b2d4add00a1738fba10e4db6eff2fab1d98 Mon Sep 17 00:00:00 2001 From: June Yi Date: Mon, 11 Oct 2021 01:45:39 +0900 Subject: [PATCH 23/43] [ko] Update outdated content in dev-1.22-ko.2 (Task M11) Co-authored-by: Seokho Son --- content/ko/docs/concepts/containers/images.md | 83 +++++++++++++++---- 1 file changed, 67 insertions(+), 16 deletions(-) diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 9a22f2f3e5..5ab09dd64a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -39,14 +39,6 @@ weight: 10 배치할 수 있는 위치에 대한 추가 규칙이 있다. 태그를 지정하지 않으면, 쿠버네티스는 태그 `latest` 를 의미한다고 가정한다. -{{< caution >}} -프로덕션에서 컨테이너를 배포할 때는 `latest` 태그를 사용하지 않아야 한다. -실행 중인 이미지 버전을 추적하기가 어렵고 -이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다. - -대신, `v1.42.0` 과 같은 의미있는 태그를 지정한다. -{{< /caution >}} - ## 이미지 업데이트 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}, @@ -57,13 +49,62 @@ weight: 10 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는 이미지에 대한 풀을 생략하게 한다. -만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다. +### 이미지 풀(pull) 정책 -- 컨테이너의 `imagePullPolicy`를 `Always`로 설정. -- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용, - 쿠버네티스는 정책을 `Always`로 설정한다. -- `imagePullPolicy`와 사용할 이미지의 태그를 생략. -- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. +컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는 +[kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다. + +다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다. + +`IfNotPresent` +: 이미지가 로컬에 없는 경우에만 내려받는다. + +`Always` +: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 + [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다. + 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. + 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 + 컨테이너를 기동할 때 사용한다. + +`Never` +: kubelet은 이미지를 가져오려고 시도하지 않는다. 이미지가 어쨌든 이미 로컬에 존재하는 + 경우, kubelet은 컨테이너 기동을 시도한다. 이외의 경우 기동은 실패한다. + 보다 자세한 내용은 [미리 내려받은 이미지](#pre-pulled-images)를 참조한다. + +이미지 제공자에 앞서 깔린 캐시의 의미 체계는 레지스트리에 안정적으로 접근할 수 있는 한, +`imagePullPolicy: Always`인 경우 조차도 효율적이다. +컨테이너 런타임은 노드에 이미 존재하는 이미지 레이어를 알고 +다시 내려받지 않는다. + +{{< note >}} +프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데, +이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다. + +대신, `v1.42.0`과 같이 의미있는 태그를 명기한다. +{{< /note >}} + +파드가 항상 컨테이너 이미지의 같은 버전을 사용하는 것을 확실히 하려면, +이미지의 다이제스트를 명기할 수 있다. +`:`를 `@`로 교체한다. +(예를 들어, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다. + +파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 +서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다. +이는 레지스트리에서 태그가 변경되는 일이 발생해도 +구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다. + +#### 기본 이미지 풀 정책 {#imagepullpolicy-defaulting} + +사용자(또는 컨트롤러)가 신규 파드를 API 서버에 요청할 때, +특정 조건에 부합하면 클러스터가 `imagePullPolicy` 필드를 설정한다. + +- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그가 + `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. +- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, + `imagePullPolicy`는 자동으로 `Always`로 설정된다. +- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. {{< note >}} 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 @@ -75,7 +116,16 @@ weight: 10 처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다. {{< /note >}} -`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. +#### 이미지 풀 강제 + +이미지를 내려받도록 강제하려면, 다음 중 한가지 방법을 사용한다. + +- 컨테이너의 `imagePullPolicy`를 `Always`로 설정한다. +- `imagePullPolicy`를 생략하고 사용할 이미지 태그로 `:latest`를 사용한다. + 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. +- `imagePullPolicy`와 사용할 이미지의 태그를 생략한다. + 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. +- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다. ### 이미지풀백오프(ImagePullBackOff) @@ -208,7 +258,7 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. -### 미리 내려받은 이미지 +### 미리 내려받은 이미지 {#pre-pulled-images} {{< note >}} 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 @@ -328,6 +378,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다. + ## {{% heading "whatsnext" %}} * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. From c739af9cf18395f972d800f87f103022a52d3f58 Mon Sep 17 00:00:00 2001 From: bang9211 Date: Thu, 28 Oct 2021 00:34:37 +0900 Subject: [PATCH 24/43] Translate tasks/access-application-cluster/ingress-minikube.md in Korean --- .../ingress-minikube.md | 319 ++++++++++++++++++ .../service/networking/example-ingress.yaml | 18 + 2 files changed, 337 insertions(+) create mode 100644 content/ko/docs/tasks/access-application-cluster/ingress-minikube.md create mode 100644 content/ko/examples/service/networking/example-ingress.yaml diff --git a/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md b/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md new file mode 100644 index 0000000000..fcc64072b7 --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md @@ -0,0 +1,319 @@ +--- +title: NGINX 인그레스(Ingress) 컨트롤러로 Minikube에서 인그레스 설정하기 +content_type: task +weight: 100 +--- + + + +[인그레스](/ko/docs/concepts/services-networking/ingress/)는 클러스터의 서비스에 대한 외부 액세스를 허용하는 규칙을 정의하는 +API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)는 인그레스에 설정된 규칙을 이행한다. + +이 페이지에서는 HTTP URI에 따라 요청을 Service web 또는 web2로 라우팅하는 간단한 인그레스를 설정하는 방법을 보여준다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Minikube 클러스터 생성하기 + +1. **터미널 실행**을 클릭한다. + + {{< kat-button >}} + +1. (선택 사항) Minikube를 로컬로 설치한 경우 다음 명령을 실행한다. + + ```shell + minikube start + ``` + +## 인그레스 컨트롤러 활성화 + +1. NGINX 인그레스 컨트롤러를 활성화하기 위해 다음 명령을 실행한다. + + ```shell + minikube addons enable ingress + ``` + +1. NGINX 인그레스 컨트롤러가 실행 중인지 확인한다. + + + {{< tabs name="tab_with_md" >}} + {{% tab name="minikube v1.19 or later" %}} +```shell +kubectl get pods -n ingress-nginx +``` + {{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}} + +Output: + +``` +NAME READY STATUS RESTARTS AGE +ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m +ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m +ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m +``` + {{% /tab %}} + + {{% tab name="minikube v1.18.1 or earlier" %}} +```shell +kubectl get pods -n kube-system +``` +{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}} + +Output: + +``` +NAME READY STATUS RESTARTS AGE +default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m +kube-addon-manager-minikube 1/1 Running 0 3m +kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m +kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m +nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m +storage-provisioner 1/1 Running 0 2m +``` + {{% /tab %}} + {{< /tabs >}} + + + + ```shell + kubectl get pods -n ingress-nginx + ``` + + {{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}} + + Output: + + ```shell + NAME READY STATUS RESTARTS AGE + ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s + ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s + ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s + ``` + + +## hello, world 앱 배포하기 + +1. 다음 명령을 사용하여 디플로이먼트(Deployment)를 생성한다. + + ```shell + kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 + ``` + + Output: + + ```shell + deployment.apps/web created + ``` + +1. 디플로이먼트를 노출시킨다. + + ```shell + kubectl expose deployment web --type=NodePort --port=8080 + ``` + + Output: + + ```shell + service/web exposed + ``` + +1. 서비스(Service)가 생성되고 노드 포트에서 사용할 수 있는지 확인한다. + + ```shell + kubectl get service web + ``` + + Output: + + ```shell + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + web NodePort 10.104.133.249 8080:31637/TCP 12m + ``` + +1. 노드포트(NodePort)를 통해 서비스에 접속한다. + + ```shell + minikube service web --url + ``` + + Output: + + ```shell + http://172.17.0.15:31637 + ``` + + {{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}} + + Output: + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + + 이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는 + 인그레스 리소스를 사용하여 앱에 액세스할 수 있다. + +## 인그레스 리소스 생성하기 + +다음 파일은 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스 리소스다. + +1. 다음 파일을 통해 `example-ingress.yaml`을 만든다. + + {{< codenew file="service/networking/example-ingress.yaml" >}} + +1. 다음 명령어를 실행하여 인그레스 리소스를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml + ``` + + Output: + + ```shell + ingress.networking.k8s.io/example-ingress created + ``` + +1. IP 주소가 설정되었는지 확인한다. + + ```shell + kubectl get ingress + ``` + + {{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}} + + ```shell + NAME CLASS HOSTS ADDRESS PORTS AGE + example-ingress hello-world.info 172.17.0.15 80 38s + ``` + +1. `/etc/hosts` 파일의 맨 아래에 다음 행을 추가한다. + + {{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}} + + ``` + 172.17.0.15 hello-world.info + ``` + + 이것은 hello-world.info에서 Minikube로 요청을 보낸다. + +1. 인그레스 컨트롤러가 트래픽을 전달하는지 확인한다. + + ```shell + curl hello-world.info + ``` + + Output: + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + + {{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info에 접속할 수 있다.{{< /note >}} + +## 두 번째 디플로이먼트 생성하기 + +1. 다음 명령을 사용하여 v2 디플로이먼트를 생성한다. + + ```shell + kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 + ``` + Output: + + ```shell + deployment.apps/web2 created + ``` + +1. 디플로이먼트를 노출시킨다. + + ```shell + kubectl expose deployment web2 --port=8080 --type=NodePort + ``` + + Output: + + ```shell + service/web2 exposed + ``` + +## 인그레스 수정하기 + +1. 기존 `example-ingress.yaml`을 편집하여 다음 줄을 추가한다. + + ```yaml + - path: /v2 + pathType: Prefix + backend: + service: + name: web2 + port: + number: 8080 + ``` + +1. 변경 사항을 적용한다. + + ```shell + kubectl apply -f example-ingress.yaml + ``` + + Output: + + ```shell + ingress.networking/example-ingress configured + ``` + +## 인그레스 테스트하기 + +1. Hello World 앱의 첫 번째 버전에 액세스한다. + + ```shell + curl hello-world.info + ``` + + Output: + + ```shell + Hello, world! + Version: 1.0.0 + Hostname: web-55b8c6998d-8k564 + ``` + +1. Hello World 앱의 두 번째 버전에 액세스한다. + + ```shell + curl hello-world.info/v2 + ``` + + Output: + + ```shell + Hello, world! + Version: 2.0.0 + Hostname: web2-75cd47646f-t8cjk + ``` + + {{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info 및 hello-world.info/v2에 접속할 수 있다.{{< /note >}} + + + + +## {{% heading "whatsnext" %}} + +* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 더 보기. +* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 더 보기. +* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 보기. + + + diff --git a/content/ko/examples/service/networking/example-ingress.yaml b/content/ko/examples/service/networking/example-ingress.yaml new file mode 100644 index 0000000000..b309d13275 --- /dev/null +++ b/content/ko/examples/service/networking/example-ingress.yaml @@ -0,0 +1,18 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: example-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: /$1 +spec: + rules: + - host: hello-world.info + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: web + port: + number: 8080 \ No newline at end of file From a3666a7dacb369f1ecadf29961e6a4bf1a312c31 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Thu, 28 Oct 2021 04:43:17 +0900 Subject: [PATCH 25/43] Update contribute/new-content of 1.22-ko.2 --- .../ko/docs/contribute/new-content/_index.md | 60 +++++++++++++++++ .../docs/contribute/new-content/overview.md | 65 ------------------- content/ko/docs/home/_index.md | 6 +- content/ko/docs/reference/_index.md | 2 + 4 files changed, 66 insertions(+), 67 deletions(-) delete mode 100644 content/ko/docs/contribute/new-content/overview.md diff --git a/content/ko/docs/contribute/new-content/_index.md b/content/ko/docs/contribute/new-content/_index.md index 2a97dcca2c..59b4b7aae4 100644 --- a/content/ko/docs/contribute/new-content/_index.md +++ b/content/ko/docs/contribute/new-content/_index.md @@ -1,4 +1,64 @@ --- title: 새로운 콘텐츠 기여하기 +content_type: concept +main_menu: true weight: 20 --- + + + +이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다. + + + + + + +## 기여에 대한 기본 사항 + +- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. +- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. +- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 + [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. +- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 + 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 + 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, + 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. +- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. + +## 시작하기 전에 {#before-you-begin} + +### CNCF CLA 서명 {#sign-the-cla} + +모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다. + +CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다. + +### 사용할 Git 브랜치를 선택한다 + +풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다. + +시나리오 | 브랜치 +:---------|:------------ +현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `main` +기능 변경 릴리스의 콘텐츠 | `dev-` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다. +다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다. + + +어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다. + +{{< note >}} +풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면, +제출자(제출자인 여러분만)가 이를 변경할 수 있다. +{{< /note >}} + +### PR 당 언어 + +PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다. + +## 기여자를 위한 도구들 + +`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다. + + diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md deleted file mode 100644 index 540f1e6c12..0000000000 --- a/content/ko/docs/contribute/new-content/overview.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: 새로운 콘텐츠 기여하기에 대한 개요 -linktitle: 개요 -content_type: concept -main_menu: true -weight: 5 ---- - - - -이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다. - - - - - - -## 기여하기에 대한 기본 - -- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. -- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. -- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. -- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 - [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. -- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 - 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 - 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, - 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. -- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. - -## 시작하기 전에 {#before-you-begin} - -### CNCF CLA 서명 {#sign-the-cla} - -모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다. - -CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다. - -### 사용할 Git 브랜치를 선택한다 - -풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다. - -시나리오 | 브랜치 -:---------|:------------ -현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `main` -기능 변경 릴리스의 콘텐츠 | `dev-` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다. -다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다. - - -어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다. - -{{< note >}} -풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면, -제출자(제출자인 여러분만)가 이를 변경할 수 있다. -{{< /note >}} - -### PR 당 언어 - -PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다. - -## 기여자를 위한 도구들 - -`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다. - - diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 82ef348775..5233856648 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -1,4 +1,6 @@ --- + + title: 쿠버네티스 문서 noedit: true cid: docsHome @@ -20,9 +22,9 @@ overview: > 쿠버네티스는 배포, 스케일링, 그리고 컨테이너화된 애플리케이션의 관리를 자동화 해주는 오픈 소스 컨테이너 오케스트레이션 엔진이다. 본 오픈 소스 프로젝트는 Cloud Native Computing Foundation(CNCF)가 주관한다. cards: - name: concepts - title: "기초 이해하기" + title: "쿠버네티스 이해하기" description: "쿠버네티스와 쿠버네티스의 기본 개념을 배운다." - button: "개념 배우기" + button: "개념 살펴보기" button_path: "/ko/docs/concepts" - name: tutorials title: "쿠버네티스 사용해보기" diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 8bfa706ea4..761c45b34f 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -64,6 +64,8 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies) * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일) +* 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는 + [포트와 프로토콜](/docs/reference/ports-and-protocols/) 리스트 ## API 설정 이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 From cd7474e1e4f19089937fdab0937b4440b1308caa Mon Sep 17 00:00:00 2001 From: msyhu Date: Sat, 30 Oct 2021 11:08:25 +0900 Subject: [PATCH 26/43] debug content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md in Korean --- content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 1e6a007cdf..d64358ec64 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -125,7 +125,7 @@ spec: 이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의 레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는 -점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다. +점을 제외하고는 `requiredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingRequiredDuringExecution` 를 제공할 계획이다. 따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이 될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고 From c86777c6a1ccddde276560a1eb96ad76c070971f Mon Sep 17 00:00:00 2001 From: June Yi Date: Sat, 23 Oct 2021 09:14:15 +0900 Subject: [PATCH 27/43] [ko] Update content/ko/docs/concepts/services-networking/ refs #30000 tasks M23, M24, M25 and M26 Co-authored-by: Seokho Son --- .../connect-applications-service.md | 2 +- .../services-networking/dns-pod-service.md | 4 +-- .../services-networking/network-policies.md | 3 +- .../concepts/services-networking/service.md | 28 +++++++++++++++++-- 4 files changed, 31 insertions(+), 6 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 2f5a9064da..2b70f86d54 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외 쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를 지원한다. 전자는 기본적으로 작동하지만 후자는 -[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다. +[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)이 필요하다. {{< note >}} 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성, 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서 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 dea7c35965..5b8dada435 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -217,13 +217,13 @@ DNS 정책은 파드별로 설정할 수 있다. - "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. 자세한 내용은 - [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 확인할 수 있다. - "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index d8926be00c..bd1bc328f8 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -154,6 +154,7 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto 의심스러운 경우, `kubectl describe` 를 사용해서 쿠버네티스가 정책을 어떻게 해석하는지 확인해본다. + __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다. 클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을 @@ -252,7 +253,7 @@ spec: ``` 위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, -네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 +네임스페이스 `default` 에 레이블이 `role=db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다. 이 필드를 사용할 때 다음의 제한 사항이 적용된다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 230b716c78..e0b022185f 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -183,6 +183,13 @@ subsets: 위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로 라우팅된다. `192.0.2.42:9376` (TCP) +{{< note >}} +쿠버네티스 API 서버는 파드에 매핑되지 않은 엔드포인트를 프록시하는 것을 허용하지 않는다. +셀렉터가 없는 서비스에 대해서 `kubectl proxy `과 같은 행위는 +이런 제약으로 인해 실패할 것이다. 이는 사용자가 쿠버네티스 API 서버를 +프록시로 사용하여 허가받지 않은 엔드포인트에 접근하는 것을 막아준다. +{{< /note >}} + ExternalName 서비스는 셀렉터가 없고 DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다. @@ -242,6 +249,24 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 낮거나 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는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의 @@ -428,8 +453,7 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다. [도커 링크 -호환](https://docs.docker.com/userguide/dockerlinks/) 변수 -([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와 +호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와 보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고, 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다. From 41a823b19483b051144fe12a5c5706867407e3e2 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Tue, 26 Oct 2021 04:42:51 +0900 Subject: [PATCH 28/43] Update highly-available-control-plane Ko --- .../highly-available-control-plane.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md index 2ee11427f3..b9949922c5 100644 --- a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md +++ b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -133,10 +133,18 @@ Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있 ## 구현 지침 -![ha-master-gce](/images/docs/ha-master-gce.png) +![ha-control-plane](/docs/images/ha-control-plane.svg) ### 개요 +위의 그림은 3개의 컨트롤 플레인 노드와 컴포넌트를 고가용 클러스터로 구성한 형상을 보여준다. 해당 컨트롤 플레인 노드의 컴포넌트들은 다음의 방법을 차용하고 있다. +- etcd: 인스턴스는 합의(consensus)를 통해서 클러스터링되어 있다. + +- 컨트롤러들, 스케줄러, 클러스터 오토-스케일러: 리스(lease) 메커니즘을 통해 클러스터에서 각각 단 하나의 인스턴스만 활성화될 것이다. + +- 애드-온(add-on) 메니저: 애드-온들이 동기화를 유지하도록 각각 독립적으로 동작한다. + +추가적으로, API 서버들 앞에서 동작하는 로드 밸런서는 내부와 외부 트래픽을 컨트롤 플레인 노드들로 연결(route)한다. 각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다. * Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다. From b5f838fb88bbd55f7449af16c00e4bf4f7dc138a Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Thu, 28 Oct 2021 03:49:42 +0900 Subject: [PATCH 29/43] Update outdated in dev-1.22-ko.2(63-66) --- .../pull-image-private-registry.md | 2 +- .../configure-pod-container/static-pod.md | 7 +++++++ .../horizontal-pod-autoscale-walkthrough.md | 20 +++++++++++-------- .../horizontal-pod-autoscale.md | 14 ++----------- 4 files changed, 22 insertions(+), 21 deletions(-) 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 2188ced539..bb14d1c0ac 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 @@ -102,7 +102,7 @@ kubectl create secret docker-registry regcred --docker-server=` 은 프라이빗 도커 저장소의 FQDN 주소이다. - 도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다. + 도커허브(DockerHub)는 `https://index.docker.io/v1/` 를 사용한다. * `` 은 도커 사용자의 계정이다. * `` 은 도커 사용자의 비밀번호이다. * `` 은 도커 사용자의 이메일 주소이다. 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 aea2fcffa1..cc837605b9 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -31,6 +31,13 @@ API 서버에서 제어될 수는 없다. 을 사용하는 것이 바람직하다. {{< /note >}} +{{< note >}} +스태틱 파드의 `spec`은 다른 API 오브젝트(예를 들면, +{{< glossary_tooltip text="서비스어카운트" term_id="service-account" >}}, +{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}, +{{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다. +{{< /note >}} + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index a3c6285aac..1ec1db988c 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -1,4 +1,9 @@ --- + + + + + title: Horizontal Pod Autoscaler 연습 content_type: task weight: 100 @@ -100,7 +105,8 @@ NAME REFERENCE TARGET MINPODS MAXPODS REPLICA php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s ``` -아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다 (``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다). +아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다. +(``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) ## 부하 증가 @@ -236,15 +242,11 @@ CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원 더 고급화된 클러스터 모니터링 설정이 필요하다. 이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다. -이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며, -대상 값과 비교하여 레플리카 개수를 결정한다. - -이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, -자원 메트릭과 매우 유사하게 동작한다. +이 메트릭은 파드들을 설명하고, 파드들 간의 평균을 내며, 대상 값과 비교하여 레플리카 개수를 결정한다. +이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, 자원 메트릭과 매우 유사하게 동작한다. 파드 메트릭은 이처럼 메트릭 블록을 사용하여 정의된다. - ```yaml type: Pods pods: @@ -395,7 +397,9 @@ object: external: metric: name: queue_messages_ready - selector: "queue=worker_tasks" + selector: + matchLabels: + queue: "worker_tasks" target: type: AverageValue averageValue: 30 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 0700f3cb8d..8ceafa7d6a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -68,14 +68,7 @@ Horizontal Pod Autoscaler는 컨트롤러 HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, `custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로 -시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는 -[메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 -참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다. - -{{< note >}} -{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} -힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨. -{{< /note >}} +시작해야 하는 메트릭-서버에 의해 제공된다. 더 자세한 정보는 [메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참조한다. 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. @@ -225,8 +218,7 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 - `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이 안정화되기까지의 시간 간격을 지정한다. Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고, - 이 시간 간격에서의 가장 큰 크기에서만 작동한다. - 기본값은 5분(`5m0s`)이다. + 이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다. {{< note >}} 이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야 @@ -345,8 +337,6 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. * 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다. -* `--horizontal-pod-autoscaler-use-rest-clients`는 `true`이거나 설정되지 않음. 이것을 false로 설정하면 더 이상 사용되지 않는 힙스터 기반 오토스케일링으로 전환된다. - 이런 다양한 메트릭 경로와 각각의 다른 점에 대한 상세 내용은 관련 디자인 제안서인 [HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md), [custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md), From 6d18d306c29f8ca378a7c12bf745fa0f8d0e9bcc Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Thu, 28 Oct 2021 04:13:23 +0900 Subject: [PATCH 30/43] Update outdated in dev-1.22-ko.2(67-71) --- content/ko/docs/tutorials/_index.md | 1 + content/ko/docs/tutorials/hello-minikube.md | 12 ++++++++---- .../stateful-application/basic-stateful-set.md | 8 +++++++- .../docs/tutorials/stateful-application/zookeeper.md | 8 ++++++++ 4 files changed, 24 insertions(+), 5 deletions(-) diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 093208f22d..0de52da42a 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -51,6 +51,7 @@ content_type: concept * [AppArmor](/ko/docs/tutorials/clusters/apparmor/) +* [seccomp](/docs/tutorials/clusters/seccomp/) ## 서비스 * [소스 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 091a1c684f..6518d0102e 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -24,8 +24,6 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 설치 안내는 [minikube 시작](https://minikube.sigs.k8s.io/docs/start/)을 참고한다. {{< /note >}} - - ## {{% heading "objectives" %}} * 샘플 애플리케이션을 minikube에 배포한다. @@ -62,16 +60,22 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port** 를 클릭. {{< note >}} -`minikube dashboard` 명령을 내리면 대시보드 애드온과 프록시가 활성화되고 해당 프록시로 접속하는 기본 웹 브라우저 창이 열린다. 대시보드에서 디플로이먼트나 서비스와 같은 쿠버네티스 자원을 생성할 수 있다. +`minikube dashboard` 명령을 내리면 대시보드 애드온과 프록시가 활성화되고 해당 프록시로 접속하는 기본 웹 브라우저 창이 열린다. +대시보드에서 디플로이먼트나 서비스와 같은 쿠버네티스 자원을 생성할 수 있다. root 환경에서 명령어를 실행하고 있다면, [URL을 이용하여 대시보드 접속하기](#open-dashboard-with-url)를 참고한다. +기본적으로 대시보드는 쿠버네티스 내부 가상 네트워크 안에서만 접근할 수 있다. +`dashboard` 명령은 쿠버네티스 가상 네트워크 외부에서 대시보드에 접근할 수 있도록 임시 프록시를 만든다. + `Ctrl+C` 를 눌러 프록시를 종료할 수 있다. 대시보드는 종료되지 않고 실행 상태로 남아 있다. +명령이 종료된 후 대시보드는 쿠버네티스 클러스터에서 계속 실행된다. +`dashboard` 명령을 다시 실행하여 대시보드에 접근하기 위한 다른 프록시를 생성할 수 있다. {{< /note >}} ## URL을 이용하여 대시보드 접속하기 {#open-dashboard-with-url} -자동으로 웹 브라우저가 열리는 것을 원치 않는다면, 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다: +자동으로 웹 브라우저가 열리는 것을 원치 않는다면, `--url` 플래그와 함께 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다. ```shell minikube dashboard --url 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 b879049c55..db500f5699 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -1,5 +1,11 @@ --- -reviewers: + + + + + + + title: 스테이트풀셋 기본 content_type: tutorial weight: 10 diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 839f7dc7b4..a9c834d7b3 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -1,4 +1,12 @@ --- + + + + + + + + title: 분산 시스템 코디네이터 ZooKeeper 실행하기 content_type: tutorial weight: 40 From 16d70bddc95375b030cb4af6855c842c1eab8ac6 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Tue, 2 Nov 2021 02:50:38 +0900 Subject: [PATCH 31/43] Fix outdated pod-topology-spread-constraints.md Korean --- .../pods/pod-topology-spread-constraints.md | 30 +++++++++++-------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 304471bb28..a7f57b4e6a 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -230,20 +230,9 @@ graph BT 이 상황을 극복하기 위해서는 사용자가 `maxSkew` 의 증가 또는 `whenUnsatisfiable: ScheduleAnyway` 를 사용하도록 제약 조건 중 하나를 수정할 수 있다. -### 규칙 +### 노드 어피니티(Affinity) 및 노드 셀렉터(Selector)와의 상호 작용 -여기에 주목할만한 몇 가지 암묵적인 규칙이 있다. - -- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. - -- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. - - 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. - 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. - -- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다. - -- 만약 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity` 가 정의되어 있으면, 일치하지 않는 노드는 무시하게 된다. +스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다. zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다. @@ -283,6 +272,21 @@ graph BT {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} +스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다. + +### 기타 눈에 띄는 의미(semantics) + +여기에 주목할만한 몇 가지 암묵적인 규칙이 있다. + +- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. + +- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. + + 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. + 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. + +- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다. + ### 클러스터 수준의 기본 제약 조건 클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본 From 70c42572afcde2f7bbed9ec231deeb00b6fd69ee Mon Sep 17 00:00:00 2001 From: June Yi Date: Sat, 23 Oct 2021 16:56:12 +0900 Subject: [PATCH 32/43] [ko] Update concepts/workloads/controllers refs #30000 tasks M29-M35 Co-authored-by: Jerry Park --- .../workloads/controllers/cron-jobs.md | 41 +++++++++++-------- .../workloads/controllers/daemonset.md | 22 +++++++++- .../workloads/controllers/deployment.md | 32 +++++++++------ .../concepts/workloads/controllers/job.md | 23 +++++++++-- .../workloads/controllers/replicaset.md | 13 ++++++ .../controllers/replicationcontroller.md | 11 +++-- .../workloads/controllers/statefulset.md | 16 ++++++++ 7 files changed, 120 insertions(+), 38 deletions(-) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 740929b05c..e2b684166f 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -17,6 +17,8 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text=" 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. +추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=