From 6fc5dff87b26f754ae710fc70e46735cf29ffcaf Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 13 Dec 2021 17:53:23 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.22-ko.4 M56-70 --- .../kubeadm/adding-windows-nodes.md | 5 +++ .../kubeadm/kubeadm-upgrade.md | 16 ------- .../administer-cluster/sysctl-cluster.md | 12 ++++-- .../configure-persistent-volume-storage.md | 11 +++-- .../pull-image-private-registry.md | 34 +++++++++------ .../extend-kubernetes/setup-konnectivity.md | 19 ++++---- .../job/parallel-processing-expansion.md | 10 ++--- .../horizontal-pod-autoscale.md | 43 +++++++++++++++++-- .../tasks/tls/managing-tls-in-a-cluster.md | 20 +++++++-- .../ko/docs/tutorials/clusters/apparmor.md | 4 +- .../create-cluster/cluster-intro.html | 2 +- .../stateful-application/zookeeper.md | 3 +- .../examples/pods/storage/pv-duplicate.yaml | 20 +++++++++ 13 files changed, 137 insertions(+), 62 deletions(-) create mode 100644 content/ko/examples/pods/storage/pv-duplicate.yaml diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e7a1b8fb79..4ce00186a3 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -1,4 +1,9 @@ --- + + + + + title: 윈도우 노드 추가 min-kubernetes-server-version: 1.17 content_type: tutorial 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 0e76e46c93..440f9d5026 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -78,10 +78,6 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리 apt-mark unhold kubeadm && \ 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 currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. @@ -175,10 +171,6 @@ sudo kubeadm upgrade apply apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - 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를 최신 패치 버전으로 바꾼다 @@ -218,10 +210,6 @@ sudo systemctl restart kubelet apt-mark unhold kubeadm && \ 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 currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -256,10 +244,6 @@ sudo systemctl restart kubelet apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - 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를 최신 패치 버전으로 바꾼다 diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index 8adf5c4564..1d738c1424 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -10,7 +10,8 @@ content_type: task {{< feature-state for_k8s_version="v1.21" state="stable" >}} 이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여 -커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다. +커널 파라미터를 어떻게 구성하고, 사용하는지를 +설명한다. ## {{% heading "prerequisites" %}} @@ -20,6 +21,7 @@ content_type: task 일부 단계에서는 실행 중인 클러스터의 kubelet에서 커맨드 라인 옵션을 재구성할 필요가 있다. + ## 모든 sysctl 파라미터 나열 @@ -57,7 +59,8 @@ sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, - `net.ipv4.tcp_syncookies`, -- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후). +- `net.ipv4.ping_group_range` (쿠버네티스 1.18 이후), +- `net.ipv4.ip_unprivileged_port_start` (쿠버네티스 1.22 이후). {{< note >}} `net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다. @@ -112,10 +115,13 @@ _네임스페이스_ sysctl만 이 방법을 사용할 수 있다. 이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나 특권있는 컨테이너의 데몬셋을 사용하여야 한다. -네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다. +네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. +securityContext는 동일한 파드의 모든 컨테이너에 적용된다. 이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인 `net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다. +스펙에 따르면 _safe_ sysctl과 _unsafe_ sysctl 간 +차이는 없다. {{< warning >}} 파라미터의 영향을 파악한 후에만 운영체제가 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 3461c57061..a2bac74f99 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -96,11 +96,10 @@ hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다. 설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고 지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가 -읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 -지정한다. 여기서는 +읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 지정한다. 여기서는 퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 `manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 -이 퍼시스턴트볼륨에 바인딩하는데 사용한다. +이 퍼시스턴트볼륨에 바인딩하는 데 사용한다. 퍼시스턴트볼륨을 생성한다. @@ -237,8 +236,14 @@ sudo rmdir /mnt/data 이제 사용자 노드에서 셸을 종료해도 된다. +## 하나의 퍼시스턴트볼륨을 두 경로에 마운트하기 +{{< codenew file="pods/storage/pv-duplicate.yaml" >}} +하나의 퍼시스턴트볼륨을 nginx 컨테이너의 두 경로에 마운트할 수 있다. + +`/usr/share/nginx/html` - 정적 웹사이트 용 +`/etc/nginx/nginx.conf` - 기본 환경 설정 용 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 bb14d1c0ac..26c02d7bfa 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 @@ -6,29 +6,36 @@ weight: 100 -이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 +이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 +{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 사용하는 파드를 생성하는 방법을 보여준다. +{{% thirdparty-content single="true" %}} + ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "task-tutorial-prereqs.md" >}} -* 이 실습을 수행하기 위해, -[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다. +* 이 실습을 수행하기 위해, `docker` 명령줄 도구와 +[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다. -## 도커 로그인 +## 도커 허브 로그인 노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다. +`docker` 도구를 사용하여 도커 허브에 로그인한다. 자세한 정보는 +[도커 ID 계정](https://docs.docker.com/docker-id/#log-in)의 _로그 인_ 섹션을 참조한다. + ```shell docker login ``` -프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자. +프롬프트가 나타나면, 도커 ID를 입력한 다음, 사용하려는 자격증명(액세스 토큰, +또는 도커 ID의 비밀번호)을 입력한다. -로그인 프로세스는 권한 토큰 정보를 가지고 있는 `config.json` 파일을 생성하거나 업데이트 한다. +로그인 프로세스를 수행하면 권한 토큰 정보를 가지고 있는 `config.json` 파일이 생성되거나 업데이트된다. [쿠버네티스가 이 파일을 어떻게 해석하는지](/ko/docs/concepts/containers/images#config-json) 참고한다. `config.json` 파일을 확인하자. @@ -171,14 +178,14 @@ janedoe:xxxxxxxxxxx ## 시크릿을 사용하는 파드 생성하기 -다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다. +다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 예제 파드의 매니페스트이다. {{< codenew file="pods/private-reg-pod.yaml" >}} -아래의 파일을 다운로드받는다. +위 파일을 컴퓨터에 다운로드한다. ```shell -wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml ``` `my-private-reg-pod.yaml` 파일 안에서, `` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다. @@ -200,9 +207,10 @@ kubectl get pod private-reg ## {{% heading "whatsnext" %}} -* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. +* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기 + * 또는 {{< api-reference page="config-and-storage-resources/secret-v1" >}} API 레퍼런스 읽어보기 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기. * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기. * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기. -* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기. -* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기. +* 파드의 [컨테이너 정의](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)의 `imagePullSecrets` 필드에 대해 읽어보기 + diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md index fdf671a52a..5bc131af19 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -11,7 +11,11 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} +쿠버네티스 클러스터가 있어야 하며, kubectl 명령줄 도구가 +클러스터와 통신하도록 설정되어 있어야 한다. 컨트롤 플레인 호스트가 아닌 +두 개 이상의 노드로 구성된 클러스터에서 이 튜토리얼을 수행하는 것을 권장한다. +클러스터가 없다면, [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)를 +이용하여 생성할 수 있다. @@ -24,16 +28,9 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록 API 서버를 구성해야 한다. -1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있는지 -확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여 -[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를 -활성화할 수 있다. - ``` - --service-account-issuer=api - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --api-audiences=system:konnectivity-server - ``` +1. [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) +기능이 활성화되어 있는지 확인한다. +쿠버네티스 v1.20부터는 기본적으로 활성화되어 있다. 1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다. 1. API 서버의 `--egress-selector-config-file` 플래그를 API 서버 송신 구성 파일의 경로로 설정한다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index fbf105024d..5870b4b314 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -178,13 +178,13 @@ kubectl delete job -l jobgroup=jobexample ```liquid -{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, +{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, { "name": "banana", "url": "http://dbpedia.org/resource/Banana", }, { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }] %} -{%- for p in params %} -{%- set name = p["name"] %} -{%- set url = p["url"] %} +{% for p in params %} +{% set name = p["name"] %} +{% set url = p["url"] %} --- apiVersion: batch/v1 kind: Job @@ -204,7 +204,7 @@ spec: image: busybox command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] restartPolicy: Never -{%- endfor %} +{% endfor %} ``` 위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해 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 96f86ac046..2b74d03b84 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -467,9 +467,7 @@ behavior: periodSeconds: 60 ``` -마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택 -전략을 추가할 수 있다. -분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소 +분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소 정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면 자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다. @@ -506,6 +504,45 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한 다시 활성화할 때까지 HPA는 대상 조정을 중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정). +### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기 + +HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의 +{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서 +`spec.replicas`의 값을 삭제하는 것이 바람직하다. +이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로) +오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를 +`spec.replicas`에 기재된 값으로 조정할 것이다. +이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다. + +`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데, +이는 이 키의 기본값이 1이기 때문이다(레퍼런스: +[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)). +값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다. +이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다. +이러한 1회성 저하를 방지하는 방법이 존재하며, +디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다. + +{{< tabs name="fix_replicas_instructions" >}} +{{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}} + +1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>` +2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이 + 업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다. +3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다. + 소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록 + 변경 사항을 커밋하고 추가 필요 단계를 수행한다. +4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다. + +{{% /tab %}} +{{% tab name="서버 쪽에 적용하기" %}} + +[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면, +정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership) +가이드라인을 참조한다. + +{{% /tab %}} +{{< /tabs >}} + ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md index d6f29e780d..58056a60b4 100644 --- a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -1,6 +1,10 @@ --- title: 클러스터에서 TLS 인증서 관리 content_type: task + + + + --- @@ -158,9 +162,19 @@ Events: ## 인증서 서명 요청 승인 받기 -인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나 -클러스터 관리자에 의해 일회성으로 수행한다. 여기에 -관련된 내용에 대한 자세한 내용은 아래에서 설명한다. +[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은 +자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다. +인증서 요청을 승인할 수 있는 권한이 있다면, +다음과 같이 `kubectl`을 사용하여 수동으로 수행할 수 있다. + +```shell +kubectl certificate approve my-svc.my-namespace +``` + +```none +certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved +``` + ## 인증서 다운로드 및 사용 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index a8facdaa67..7dde58e298 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -233,7 +233,7 @@ kubectl get events | grep hello-apparmor proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다. ```shell -kubectl exec hello-apparmor cat /proc/1/attr/current +kubectl exec hello-apparmor -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) @@ -242,7 +242,7 @@ k8s-apparmor-example-deny-write (enforce) 마지막으로 파일 쓰기를 통해 프로파일을 위반하면 어떻게 되는지 확인할 수 있다. ```shell -kubectl exec hello-apparmor touch /tmp/test +kubectl exec hello-apparmor -- touch /tmp/test ``` ``` touch: /tmp/test: Permission denied diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index da8cce3e17..415b79362b 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -72,7 +72,7 @@ weight: 10

컨트롤 플레인은 클러스터 관리를 담당한다. 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.

-

노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다. 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.

+

노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다. 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 하는데, 이는 한 노드가 다운되면 etcd 멤버와 컨트롤 플레인 인스턴스가 사라져 중복성(redundancy)을 잃기 때문이다. 컨트롤 플레인 노드를 추가하여 이러한 위험을 줄일 수 있다.

diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 248d6d1d4d..392612e059 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -894,8 +894,7 @@ kubernetes-node-2g2d kubectl get nodes ``` -[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여 -클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자. +이 튜토리얼에서는 클러스터가 최소 4개의 노드로 구성되었다고 가정한다. 클러스터의 노드가 4개보다 많다면, [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) 명령을 이용하여 4개 노드를 제외하고 다른 모든 노드를 통제(cordon)한다. 이렇게 4개 노드만 사용하도록 제한하여, 다음의 유지보수 시뮬레이션 예시에서 주키퍼 파드를 스케줄링할 때 어피니티와 PodDisruptionBudget 제약이 발생하도록 할 수 있다. ```shell kubectl cordon <노드-이름> diff --git a/content/ko/examples/pods/storage/pv-duplicate.yaml b/content/ko/examples/pods/storage/pv-duplicate.yaml new file mode 100644 index 0000000000..15a48acbed --- /dev/null +++ b/content/ko/examples/pods/storage/pv-duplicate.yaml @@ -0,0 +1,20 @@ + +apiVersion: v1 +kind: Pod +metadata: + name: test +spec: + containers: + - name: test + image: nginx + volumeMounts: + - name: site-data + mountPath: /usr/share/nginx/html + subPath: html + - name: config + mountPath: /etc/nginx/nginx.conf + subPath: nginx.conf + volumes: + - name: config + persistentVolumeClaim: + claimName: test-nfs-claim \ No newline at end of file