diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 34bc413e7496d..89b8e7910cd5f 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -41,7 +41,7 @@ weight: 40 * [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) * [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/) * [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) -* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) ## 쿠버네티스 컨트롤 플레인 @@ -66,6 +66,5 @@ weight: 40 개념 페이지를 작성하기를 원하면, -개념 페이지 유형에 대한 정보가 있는 -[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다. - +개념 페이지 타입에 대한 정보가 있는 +[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다. diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 91e1a4e7ac3f4..3d5ba7e9d08d9 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -99,7 +99,7 @@ _어노테이션_ 을 사용하여 AWS의 로드 밸런서 서비스에 다른 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 서비스에서 연결 드레이닝 타임아웃 값을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: 서비스에서 유휴 연결 타임아웃 값을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: 서비스에서 교차 영역의 로드 밸런싱을 활성화하거나 비활성화하는 데 사용된다. -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. 여기에 정의된 보안 그룹은 서비스 간에 공유해서는 안된다. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 서비스에서 생성된 ELB에 추가할 추가적인 보안 그룹을 지정하는 데 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-internal`: 서비스에서 내부 ELB 사용 희망을 표시하기 위해 사용된다. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: 서비스에서 ELB에서 프록시 프로토콜을 활성화하는 데 사용된다. 현재는 모든 ELB 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다. diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index f61add3919107..542fef1bcc01f 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -60,7 +60,7 @@ metadata: name: game-demo data: # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨 - player_initial_lives: 3 + player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # 파일과 비슷한 키 @@ -85,9 +85,9 @@ data: 방식에 따라 다르게 쓰인다. 처음 세 가지 방법의 경우, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 파드의 컨테이너를 시작할 때 -시크릿의 데이터를 사용한다. +컨피그맵의 데이터를 사용한다. -네 번째 방법은 시크릿과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. +네 번째 방법은 컨피그맵과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. 그러나, 쿠버네티스 API를 직접 사용하기 때문에, 애플리케이션은 컨피그맵이 변경될 때마다 업데이트를 받기 위해 구독할 수 있고, 업데이트가 있으면 반응한다. 쿠버네티스 API에 직접 접근하면, 이 @@ -168,7 +168,7 @@ spec: 파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다. 1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다. -1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다. +1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다. 1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. 1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다. @@ -250,4 +250,3 @@ immutable: true * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다. * 코드를 구성에서 분리하려는 동기를 이해하려면 [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. - diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index d818aeae0b143..98861cc1b9e3b 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -32,7 +32,7 @@ weight: 10 - 가능하다면 단독 파드(즉, [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. - 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다. + 명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/ko/docs/concepts/workloads/controllers/job/) 또한 적절할 수 있다. ## 서비스 @@ -61,7 +61,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 ## 레이블 사용하기 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다. @@ -101,6 +101,4 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다. -- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. - - +- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 4a8a6b7f2febf..998456ca4968e 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -128,23 +128,23 @@ CPU: 1 Node Score: intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) - = 7 + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 # requested + used = 75% * available + = rawScoringFunction(75) + = 7 # floor(75/10) Memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) - = 50 + = 50 # requested + used = 50% * available = rawScoringFunction(50) - = 5 + = 5 # floor(50/10) CPU = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) - = 37.5 + = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) - = 3 + = 3 # floor(37.5/10) NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 @@ -189,5 +189,3 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` - - diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index f03847c38c08e..34c90ad36b269 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -6,18 +6,51 @@ weight: 10 -사용자 Docker 이미지를 생성하고 레지스트리에 푸시(push)하여 쿠버네티스 파드에서 참조되기 이전에 대비한다. +컨테이너 이미지는 애플리케이션과 모든 소프트웨어 의존성을 캡슐화하는 바이너리 데이터를 +나타낸다. 컨테이너 이미지는 독립적으로 실행할 수 있고 런타임 환경에 대해 +잘 정의된 가정을 만드는 실행 가능한 소프트웨어 번들이다. -컨테이너의 `image` 속성은 `docker` 커맨드에서 지원하는 문법과 같은 문법을 지원한다. 이는 프라이빗 레지스트리와 태그를 포함한다. +일반적으로 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 +참조하기 전에 애플리케이션의 컨테이너 이미지를 +생성해서 레지스트리로 푸시한다. + +이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. +## 이미지 이름 + +컨테이너 이미지는 일반적으로 `pause`, `example/mycontainer` 또는 `kube-apiserver` 와 같은 이름을 부여한다. +이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, `fictional.registry.example/imagename` +과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, `fictional.registry.example:10443/imagename` 과 같다. + +레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다. + +이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 와 `podman` +등의 명령과 함께 사용). +태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다. + +이미지 태그는 소문자와 대문자, 숫자, 밑줄(`_`), +마침표(`.`) 및 대시(`-`)로 구성된다. +이미지 태그 안에서 구분 문자(`_`, `-` 그리고 `.`)를 +배치할 수 있는 위치에 대한 추가 규칙이 있다. +태그를 지정하지 않으면, 쿠버네티스는 태그 `latest` 를 의미한다고 가정한다. + +{{< caution >}} +프로덕션에서 컨테이너를 배포할 때는 `latest` 태그를 사용하지 않아야 한다. +실행 중인 이미지 버전을 추적하기가 어렵고 +이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다. + +대신, `v1.42.0` 과 같은 의미있는 태그를 지정한다. +{{< /caution >}} + ## 이미지 업데이트 -기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 Kubelet이 이미 +기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다. @@ -26,46 +59,18 @@ weight: 10 - `imagePullPolicy`와 사용할 이미지의 태그를 생략. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. -`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다. +`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. -## 매니페스트로 멀티-아키텍처 이미지 빌드 - -Docker CLI는 현재 `docker manifest` 커맨드와 `create`, `annotate`, `push`와 같은 서브 커맨드를 함께 지원한다. 이 커맨드는 매니페스트를 빌드하고 푸시하는데 사용할 수 있다. 매니페스트를 보기 위해서는 `docker manifest inspect`를 사용하면 된다. - -다음에서 docker 문서를 확인하기 바란다. -https://docs.docker.com/edge/engine/reference/commandline/manifest/ - -이것을 사용하는 방법에 대한 예제는 빌드 하니스(harness)에서 참조한다. -https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos= - -이 커맨드는 Docker CLI에 의존하며 그에 전적으로 구현된다. `$HOME/.docker/config.json` 편집 및 `experimental` 키를 `enabled`로 설정하거나, CLI 커맨드 호출 시 간단히 `DOCKER_CLI_EXPERIMENTAL` 환경 변수를 `enabled`로만 설정해도 된다. - -{{< note >}} -Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전은 버그가 있거나 실험적인 명령줄 옵션을 지원하지 않는다. 예를 들어 https://github.com/docker/cli/issues/1135 는 containerd에서 문제를 일으킨다. -{{< /note >}} +## 매니페스트가 있는 다중 아키텍처 이미지 -오래된 매니페스트 업로드를 실행하는 데 어려움을 겪는다면, `$HOME/.docker/manifests`에서 오래된 매니페스트를 정리하여 새롭게 시작하면 된다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 제공할 수도 있다. 매니페스트는 아키텍처별 버전의 컨테이너에 대한 이미지 매니페스트를 참조할 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. -쿠버네티스의 경우, 일반적으로 접미사 `-$(ARCH)`가 있는 이미지를 사용해 왔다. 하위 호환성을 위해, 접미사가 있는 구형 이미지를 생성하길 바란다. 접미사에 대한 아이디어는 모든 아키텍처를 위한 매니페스트를 가졌다는 의미가 내포된 `pause` 이미지를 생성하고, 접미사가 붙은 이미지가 하드 코드되어 있을 오래된 구성 또는 YAML 파일에 대해 하위 호환된다는 의미가 내포되어 있는 `pause-amd64`를 생성하기 위한 것이다. +쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. ## 프라이빗 레지스트리 사용 프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다. 자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다. - - - Google 컨테이너 레지스트리 사용 - - 각 클러스터에 대하여 - - Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨 - - 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음 - - AWS Elastic Container Registry(ECR) 사용 - - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함 - - ECR 로그인 자격 증명은 자동으로 갱신됨 - - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 - - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - - Azure 컨테이너 레지스트리(ACR) 사용 - - IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함 - - IBM 클라우드 컨테이너 레지스트리 사용 - - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 @@ -74,139 +79,57 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 - 파드에 ImagePullSecrets을 명시 - 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능 + - 공급 업체별 또는 로컬 확장 + - 사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드 + 제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을 + 구현할 수 있다. -각 옵션은 아래에서 더 자세히 설명한다. - - -### Google 컨테이너 레지스트리 사용 - -쿠버네티스는 Google 컴퓨트 엔진(GCE)에서 동작할 때, [Google 컨테이너 -레지스트리(GCR)](https://cloud.google.com/tools/container-registry/)를 자연스럽게 -지원한다. 사용자의 클러스터가 GCE 또는 Google 쿠버네티스 엔진에서 동작 중이라면, 간단히 -이미지의 전체 이름(예: gcr.io/my_project/image:tag)을 사용하면 된다. - -클러스터 내에서 모든 파드는 해당 레지스트리에 있는 이미지에 읽기 접근 권한을 가질 것이다. - -Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 -GCR을 인증할 것이다. 인스턴스의 서비스 계정은 -`https://www.googleapis.com/auth/devstorage.read_only`라서, -프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다. - -### Amazon Elastic Container Registry 사용 - -쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. - -간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을 -파드 정의에 사용하면 된다. - -파드를 생성할 수 있는 클러스터의 모든 사용자는 ECR 레지스트리에 있는 어떠한 -이미지든지 파드를 실행하는데 사용할 수 있다. - -kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다. 이것을 위해서는 다음에 대한 권한이 필요하다. - -- `ecr:GetAuthorizationToken` -- `ecr:BatchCheckLayerAvailability` -- `ecr:GetDownloadUrlForLayer` -- `ecr:GetRepositoryPolicy` -- `ecr:DescribeRepositories` -- `ecr:ListImages` -- `ecr:BatchGetImage` - -요구 사항: - -- Kubelet 버전 `v1.2.0` 이상을 사용해야 한다. (예: `/usr/bin/kubelet --version=true`를 실행). -- 노드가 지역 A에 있고 레지스트리가 다른 지역 B에 있다면, 버전 `v1.3.0` 이상이 필요하다. -- 사용자의 지역에서 ECR이 지원되어야 한다. +이들 옵션은 아래에서 더 자세히 설명한다. -문제 해결: +### 프라이빗 레지스트리에 인증하도록 노드 구성 -- 위의 모든 요구 사항을 확인한다. -- 워크스테이션에서 $REGION (예: `us-west-2`)의 자격 증명을 얻는다. 그 자격 증명을 사용하여 해당 호스트로 SSH를 하고 Docker를 수동으로 실행한다. 작동하는가? -- kubelet이 `--cloud-provider=aws`로 실행 중인지 확인한다. -- kubelet 로그 수준을 최소 3 이상으로 늘리고 kubelet 로그에서 (예: `journalctl -u kubelet`) 다음과 같은 로그 라인을 확인한다. - - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` - - `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` +노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록 +도커 컨테이너 런타임을 구성할 수 있다. -### Azure 컨테이너 레지스트리(ACR) 사용 -쿠버네티스는 Azure 쿠버네티스 서비스(AKS)를 사용할 때 -[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를 -기본적으로 지원한다. - -AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다. 구성에 대한 -지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다. 그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다. - -ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다. -어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은 -[azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다. - -우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는 -[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. - -컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다. - - * `DOCKER_USER` : 서비스 주체 또는 관리자 역할의 사용자명 - * `DOCKER_PASSWORD`: 서비스 주체 패스워드 또는 관리자 역할의 사용자 패스워드 - * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` - * `DOCKER_EMAIL`: `${some-email-address}` - -해당 변수에 대한 값을 채우고 나면 -[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다. - -### IBM 클라우드 컨테이너 레지스트리 사용 -IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다. - -IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started)를 참고한다. - -다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다. - -### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - -{{< note >}} -Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} +이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다. {{< note >}} -AWS EC2에서 동작 중이고 EC2 컨테이너 레지스트리(ECR)을 사용 중이라면, 각 노드의 kubelet은 -ECR 로그인 자격 증명을 관리하고 업데이트할 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} - -{{< note >}} -이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 -GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 -않을 것이다. -{{< /note >}} - -{{< note >}} -현재 쿠버네티스는 docker 설정의 `auths`와 `HttpHeaders` 섹션만 지원한다. 이는 자격증명 도우미(`credHelpers` 또는 `credStore`)가 지원되지 않는다는 뜻이다. +쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다. +도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다. {{< /note >}} -Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 +도커는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다. -* `{--root-dir:-/var/lib/kubelet}/config.json` -* `{cwd of kubelet}/config.json` -* `${HOME}/.docker/config.json` -* `/.docker/config.json` -* `{--root-dir:-/var/lib/kubelet}/.dockercfg` -* `{cwd of kubelet}/.dockercfg` -* `${HOME}/.dockercfg` -* `/.dockercfg` +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` {{< note >}} -아마도 kubelet을 위한 사용자의 환경 파일에 `HOME=/root`을 명시적으로 설정해야 할 것이다. +kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설정해야 할 수 있다. {{< /note >}} 프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이 예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다. - 1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 `$HOME/.docker/config.json`를 업데이트한다. + 1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다. 1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다. 1. 노드의 리스트를 구한다. 예를 들면 다음과 같다. - - 이름을 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` - - IP를 원하는 경우: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` + - 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 1. 로컬의 `.docker/config.json`를 위의 검색 경로 리스트 중 하나에 복사한다. - - 예: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` + - 이를 테스트하기 위한 예: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + +{{< note >}} +프로덕션 클러스터의 경우, 이 설정을 필요한 모든 노드에 적용할 수 있도록 +구성 관리 도구를 사용한다. +{{< /note >}} 프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다. @@ -263,11 +186,11 @@ Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Go {{< note >}} 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 -GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지 -않을 것이다. +클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로 +작동하지 않을 것이다. {{< /note >}} -기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 할 것이다. +기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 한다. 그러나, 컨테이너의 `imagePullPolicy` 속성이 `IfNotPresent` 또는 `Never`으로 설정되어 있다면, 로컬 이미지가 사용된다(우선적으로 또는 배타적으로). @@ -281,13 +204,13 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 ### 파드에 ImagePullSecrets 명시 {{< note >}} -이 방법은 현재 Google 쿠버네티스 엔진, GCE 및 노드 생성이 자동화된 모든 클라우드 제공자에게 +이 방법은 프라이빗 레지스트리의 이미지를 기반으로 컨테이너를 실행하는 데 권장된다. {{< /note >}} -쿠버네티스는 파드에 레지스트리 키를 명시하는 것을 지원한다. +쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다. -#### Docker 구성으로 시크릿 생성 +#### 도커 구성으로 시크릿 생성 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다. @@ -295,12 +218,14 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL ``` -만약 Docker 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, -자격 증명 파일을 쿠버네티스 시크릿으로 가져올 수 있다. -[기존 Docker 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. +만약 도커 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, +자격 증명 파일을 쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}으로 +가져올 수 있다. +[기존 도커 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. + `kubectl create secret docker-registry`는 -하나의 개인 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, -여러 개인 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. +하나의 프라이빗 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, +여러 프라이빗 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. {{< note >}} 파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다. @@ -312,6 +237,8 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER 이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을 참조하는 파드를 생성할 수 있다. +예를 들면 다음과 같다. + ```shell cat < pod.yaml apiVersion: v1 @@ -337,28 +264,29 @@ EOF 그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/user-guide/service-accounts) 리소스에 imagePullSecrets을 셋팅하여 자동화할 수 있다. + 자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다. 이것은 노드 당 `.docker/config.json`와 함께 사용할 수 있다. 자격 증명은 -병합될 것이다. 이 방법은 Google 쿠버네티스 엔진에서 작동될 것이다. +병합될 것이다. -### 유스케이스 +## 유스케이스 프라이빗 레지스트리를 구성하기 위한 많은 솔루션이 있다. 다음은 여러 가지 일반적인 유스케이스와 제안된 솔루션이다. 1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다. - - Docker hub의 퍼블릭 이미지를 사용한다. + - 도커 허브의 퍼블릭 이미지를 사용한다. - 설정이 필요 없다. - - GCE 및 Google 쿠버네티스 엔진에서는, 속도와 가용성 향상을 위해서 로컬 미러가 자동적으로 사용된다. + - 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다. 1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를 실행하는 클러스터의 경우. - - 호스트 된 프라이빗 [Docker 레지스트리](https://docs.docker.com/registry/)를 사용한다. - - 그것은 [Docker Hub](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다. + - 호스트 된 프라이빗 [도커 레지스트리](https://docs.docker.com/registry/)를 사용한다. + - 그것은 [도커 허브](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다. - 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다. - 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다. - 쿠버네티스 구성은 필요 없다. - - 또는, GCE 및 Google 쿠버네티스 엔진에서는, 프로젝트의 Google 컨테이너 레지스트리를 사용한다. + - 이미지 접근을 제어하는 ​​호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다. - 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다. - 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다. 1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우. @@ -372,5 +300,8 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. -Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. +Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다. + +## {{% heading "whatsnext" %}} +* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기 diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index ecf57f49fcf68..5a1ee8024cd69 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -45,7 +45,7 @@ weight: 10 이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. 대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. -결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 있고 +결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. ## 익스텐션 패턴 @@ -202,5 +202,3 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 * [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/) * [kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 * [오퍼레이터 패턴](/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 - - diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index f94ab988a33dc..ad083dd49df08 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -71,7 +71,7 @@ card: ## 쿠버네티스가 아닌 것 -쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. +쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. 쿠버네티스는: @@ -89,4 +89,3 @@ card: * [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 * [시작하기](/ko/docs/setup/) 준비가 되었는가? - 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 d5eb45f21c4e9..ec4df0668d323 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -27,7 +27,7 @@ weight: 30 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다. -이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 +이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근 제어 정책을 갖게 된다. 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 @@ -39,6 +39,10 @@ weight: 30 네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. +{{< note >}} + 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. +{{< /note >}} + ### 네임스페이스 조회 사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다. @@ -54,11 +58,12 @@ kube-public Active 1d kube-system Active 1d ``` -쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다. +쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다. * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. + * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스 ### 요청에 네임스페이스 설정하기 @@ -114,6 +119,3 @@ kubectl api-resources --namespaced=false * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. * [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기. - - - diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 9b59aae529bfe..d390188c5169e 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -7,7 +7,7 @@ weight: 15 `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을 -제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 +제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다. @@ -40,12 +40,6 @@ weight: 15 디플로이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동시킨다. -```sh -kubectl run nginx --image nginx -``` - -다른 문법을 이용하여 동일한 작업을 수행한다. - ```sh kubectl create deployment nginx --image nginx ``` @@ -75,11 +69,11 @@ kubectl create deployment nginx --image nginx 참고한다. {{< warning >}} -명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 -구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. -이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 -사용하지 말아야한다. -예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 +명령형 `replace` 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고 +구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. +이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 +사용하지 말아야한다. +예를 들어 `LoadBalancer` 유형의 서비스는 클러스터의 구성과 별도로 `externalIPs` 필드가 업데이트된다. {{< /warning >}} @@ -132,14 +126,14 @@ kubectl replace -f nginx.yaml 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 -`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 +`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다. {{< note >}} -선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 -다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. +선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 +다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. 이것은 전체 오브젝트 구성 변경을 위한 `replace` API를 -사용하는 대신, `patch` API를 사용하여 인지되는 차이만 +사용하는 대신, `patch` API를 사용하여 인지되는 차이만 작성하기 때문에 가능하다. {{< /note >}} @@ -185,5 +179,3 @@ kubectl apply -R -f configs/ - [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl 서적](https://kubectl.docs.kubernetes.io) - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - - diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index b64f946acc871..bcbc22d915066 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -1,59 +1,53 @@ --- title: 클라우드 네이티브 보안 개요 content_type: concept -weight: 1 +weight: 10 --- -{{< toc >}} - -쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 -방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 -수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, -전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 -몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 -몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 -소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 -한다. +이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다. + +{{< warning >}} +이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다. +{{< /warning >}} ## 클라우드 네이티브 보안의 4C -계층적인 보안에 대해서 어떻게 생각할 수 있는지 이해하는 데 도움이 될 수 있는 다이어그램부터 살펴보자. + +보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud), +클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다. + {{< note >}} 이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 -널리 알려져 있다. 4C는 클라우드(Cloud), 클러스터(Clusters), 컨테이너(Containers) 및 코드(Code)이다. +컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 +널리 알려져 있다. {{< /note >}} {{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" >}} - -위 그림에서 볼 수 있듯이, -4C는 각각의 사각형의 보안에 따라 다르다. 코드 -수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 -보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 -처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 -강화될 것이다. 이러한 관심 분야는 아래에서 더 자세히 설명한다. +클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다. +코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다. +코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준을 +보호할 수 없다. ## 클라우드 여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 [신뢰 컴퓨팅 기반(trusted computing base)](https://en.wikipedia.org/wiki/Trusted_computing_base) -이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) -경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 -실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 -안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 -제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 -클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 -알려진 클라우드 공급자의 보안 문서의 일부와 -쿠버네티스 클러스터를 구성하기 위한 인프라 -보안에 대한 일반적인 지침을 제공한다. +이다. 클라우드 계층이 취약하거나 취약한 방식으로 +구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는 +보장은 없다. 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 +위한 보안 권장 사항을 제시한다. -### 클라우드 공급자 보안 표 +### 클라우드 공급자 보안 +자신의 하드웨어 또는 다른 클라우드 공급자에서 쿠버네티스 클러스터를 실행 중인 경우, +보안 모범 사례는 설명서를 참고한다. +다음은 인기있는 클라우드 공급자의 보안 문서 중 일부에 대한 링크이다. +{{< table caption="클라우드 공급자 보안" >}} IaaS 공급자 | 링크 | -------------------- | ------------ | @@ -64,43 +58,46 @@ IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | +{{< /table >}} + +### 인프라스트럭처 보안 {#infrastructure-security} -자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 -모범 사례는 해당 문서를 참조한다. +쿠버네티스 클러스터에서 인프라 보안을 위한 제안은 다음과 같다. -### 일반적인 인프라 지침 표 +{{< table caption="인프라스트럭처 보안" >}} 쿠버네티스 인프라에서 고려할 영역 | 추천 | --------------------------------------------- | ------------ | -API 서버에 대한 네트워크 접근(마스터) | 이상적으로는 인터넷에서 쿠버네티스 마스터에 대한 모든 접근을 공개적으로 허용하지 않으며 클러스터를 관리하는데 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록(ACL)에 의해 제어되어야 한다. | -노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. -클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 마스터 및 노드에 서로 다른 권한을 부여해야 함으로써, 이런 권장 사항이 더 일반적이다. 관리해야 하는 리소스에 대한 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. AWS의 Kops에 대한 예제: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles -etcd에 대한 접근 | etcd (쿠버네티스의 데이터저장소)에 대한 접근은 마스터로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 정보: https://github.com/etcd-io/etcd/tree/master/Documentation#security -etcd 암호화 | 가능한 모든 드라이브를 유휴 상태에서 암호화 하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 디스크의 암호화는 유휴 상태에서 암호화 되어야 한다. +API 서버에 대한 네트워크 접근(컨트롤 플레인) | 쿠버네티스 컨트롤 플레인에 대한 모든 접근은 인터넷에서 공개적으로 허용되지 않으며 클러스터 관리에 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록에 의해 제어된다. | +노드에 대한 네트워크 접근(노드) | 지정된 포트의 컨트롤 플레인에서 _만_ (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. +클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. [Kops 설명서](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)는 IAM 정책 및 역할에 대한 정보를 제공한다. +etcd에 대한 접근 | etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 [etcd 문서](https://github.com/etcd-io/etcd/tree/master/Documentation)에서 확인할 수 있다. +etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다. + +{{< /table >}} ## 클러스터 -이 섹션에서는 쿠버네티스의 워크로드 -보안을 위한 링크를 제공한다. 쿠버네티스 -보안에 영향을 미치는 다음 두 가지 영역이 있다. +쿠버네티스 보안에는 다음의 두 가지 영역이 있다. -* 클러스터를 구성하는 설정 가능한 컴포넌트의 보안 -* 클러스터에서 실행되는 컴포넌트의 보안 +* 설정 가능한 클러스터 컴포넌트의 보안 +* 클러스터에서 실행되는 애플리케이션의 보안 -### 클러스터_의_ 컴포넌트 +### 클러스터의 컴포넌트 {#cluster-components} 우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, 모범 사례에 대한 정보를 채택하기 위해서는 [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대한 조언을 읽고 따른다. -### 클러스터 _내_ 컴포넌트(애플리케이션) +### 클러스터 내 컴포넌트(애플리케이션) {#cluster-applications} + 애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, -리소스 제한을 설정하지 않은 서비스 B에 의해 -서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 -실행 중인 워크로드를 보호할 때 고려해야 할 사항에 대한 링크 표이다. +서비스 B의 리소스를 제한하지 않으면 +서비스 A가 손상될 위험이 높다. 다음은 쿠버네티스에서 +실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 표이다. 워크로드 보안에서 고려할 영역 | 추천 | ------------------------------ | ------------ | @@ -112,51 +109,45 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/ 쿠버네티스 인그레스를 위한 TLS | https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls - - ## 컨테이너 -쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, -쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 -반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 -또한 이 가이드의 범위를 벗어나지만, 해당 주제에 대한 추가적인 설명을 위하여 -일반 권장사항 및 링크 표를 아래에 제공한다. +컨테이너 보안은 이 가이드의 범위를 벗어난다. 다음은 일반적인 권장사항과 +이 주제에 대한 링크이다. 컨테이너에서 고려할 영역 | 추천 | ------------------------------ | ------------ | -컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부 또는 정기적으로 [CoreOS의 Clair](https://github.com/coreos/clair/)와 같은 도구를 사용해서 컨테이너에 알려진 취약점이 있는지 검사한다. -이미지 서명 및 시행 | 두 개의 다른 CNCF 프로젝트(TUF 와 Notary)는 컨테이너 이미지에 서명하고 컨테이너 내용에 대한 신뢰 시스템을 유지하는데 유용한 도구이다. 도커를 사용하는 경우 도커 엔진에 [도커 컨텐츠 신뢰](https://docs.docker.com/engine/security/trust/content_trust/)가 내장되어 있다. 시행 부분에서의 [IBM의 Portieris](https://github.com/IBM/portieris) 프로젝트는 쿠버네티스 다이나믹 어드미션 컨트롤러로 실행되는 도구로, 클러스터에서 허가하기 전에 Notary를 통해 이미지가 적절하게 서명되었는지 확인한다. +컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다. +이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다. 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다. ## 코드 -마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 -주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 -밖이지만 몇 가지 권장사항이 있다. +애플리케이션 코드는 가장 많은 제어를 할 수 있는 주요 공격 영역 중 하나이다. +애플리케이션 코드 보안은 쿠버네티스 보안 주제를 벗어나지만, +애플리케이션 코드를 보호하기 위한 권장 사항은 다음과 같다. -### 일반적인 코드 보안 지침표 +### 코드 보안 + +{{< table caption="코드 보안" >}} 코드에서 고려할 영역 | 추천 | ---------------------------------------------- | ------------ | -TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이언트와 먼저 TLS 핸드 셰이크를 수행하는 것이 이상적이다. 몇 가지 경우를 제외하고, 기본 동작은 전송 중인 모든 것을 암호화하는 것이다. 한걸음 더 나아가, VPC의 "방화벽 뒤"에서도 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. 이것을 수행하기 위해 쿠버네티스에는 [Linkerd](https://linkerd.io/) 및 [Istio](https://istio.io/)와 같은 수많은 도구가 있다. | +-------------------------| -------------- | +TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. | 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. | -타사 종속성 보안 | 애플리케이션은 자체 코드베이스의 외부에 종속적인 경향이 있기 때문에, 코드의 종속성을 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | +타사 종속성 보안 | 애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | 정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools | -동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://owasp.org/www-project-zap/ | - - -## 강력한(robust) 자동화 - -위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 -전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 -"지속적인 해킹(Continuous Hacking)"에 대한 접근 방식에 대해 알아 보려면, 자세한 설명을 제공하는 [이 기사](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/)를 참고한다. +동적 탐지 공격 | 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 여기에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 [OWASP Zed Attack 프록시](https://owasp.org/www-project-zap/)이다. | +{{< /table >}} ## {{% heading "whatsnext" %}} -* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) 알아보기 -* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대해 알아보기 -* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)에 대해 알아보기 -* 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기 -* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기 -* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기 +쿠버네티스 보안 주제에 관련한 내용들을 배워보자. + +* [파드 보안 표준](/docs/concepts/security/pod-security-standards/) +* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) +* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/) +* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/) +* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) +* [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) +* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/) diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index ad5b1f9bbbf8f..be39f13f210c0 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -2,27 +2,28 @@ title: HostAliases로 파드의 /etc/hosts 항목 추가하기 content_type: concept weight: 60 +min-kubernetes-server-version: 1.7 --- -{{< toc >}} -파드의 /etc/hosts 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. 1.7 버전에서는, 사용자들이 PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. -HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 Kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. +파드의 `/etc/hosts` 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. + +HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. ## 기본 호스트 파일 내용 -파드 IP가 할당된 Nginx 파드를 시작해보자. +파드 IP가 할당된 Nginx 파드를 시작한다. ```shell -kubectl run nginx --image nginx --generator=run-pod/v1 +kubectl run nginx --image nginx ``` -```shell +``` pod/nginx created ``` @@ -32,7 +33,7 @@ pod/nginx created kubectl get pods --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` @@ -43,7 +44,7 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0 kubectl exec nginx -- cat /etc/hosts ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -57,43 +58,44 @@ fe00::2 ip6-allrouters 기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 상용구들만 포함하고 있다. -## HostAliases를 사용하여 추가 항목들 추가하기 +## hostAliases를 사용하여 추가 항목들 추가하기 -기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, -`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록 -추가 항목들을 `hosts` 파일에 추가할 수 있으며, -이는 `.spec.hostAliases` 항목에서 정의하여 파드에 HostAliases를 추가하면 가능하다. +기본 상용구 이외에, 추가 항목들을 `hosts` 파일에 +추가할 수 있다. +예를 들어, `foo.local`, `bar.local`이 `127.0.0.1`로, +`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록, `.spec.hostAliases` 항목에서 정의하여 파드에 +HostAliases를 추가하면 가능하다. {{< codenew file="service/networking/hostaliases-pod.yaml" >}} -이 파드는 다음의 명령어를 통해 시작될 수 있다. +다음을 실행하여 해당 구성으로 파드를 실행할 수 있다. ```shell -kubectl apply -f hostaliases-pod.yaml +kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` -```shell +``` pod/hostaliases-pod created ``` -파드의 IP와 상태를 확인해보자. +파드의 세부 정보를 검토하여 IPv4 주소와 상태를 확인해보자. ```shell kubectl get pod --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 ``` -`hosts` 파일 내용은 아래와 같을 것이다. +`hosts` 파일 내용은 아래와 같다. ```shell -kubectl exec hostaliases-pod -- cat /etc/hosts +kubectl logs hostaliases-pod ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -110,14 +112,16 @@ fe00::2 ip6-allrouters 가장 마지막에 추가 항목들이 정의되어 있는 것을 확인할 수 있다. -## 왜 Kubelet이 호스트 파일을 관리하는가? +## 왜 Kubelet이 호스트 파일을 관리하는가? {#why-does-kubelet-manage-the-hosts-file} 컨테이너가 이미 시작되고 난 후 도커가 파일을 [수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 [관리](https://github.com/kubernetes/kubernetes/issues/14633)한다. -호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 -`hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이 -덮어 쓰인다. 따라서, 호스트 파일의 내용을 -직접 바꾸는 것은 권장하지 않는다. +{{< caution >}} +컨테이너 내부의 호스트 파일을 수동으로 변경하면 안된다. + +호스트 파일을 수동으로 변경하면, +컨테이너가 종료되면 변경 사항이 손실된다. +{{< /caution >}} diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index cc31fae666ba3..bdf1920567d8b 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -6,7 +6,7 @@ weight: 30 -이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다. +이 문서는 쿠버네티스의 볼륨스냅샷클래스(VolumeSnapshotClass) 개요를 설명한다. [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다. @@ -17,29 +17,42 @@ weight: 30 ## 소개 -`StorageClass` 는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를 -설명하는 방법을 제공하는 것처럼, `VolumeSnapshotClass` 는 볼륨 스냅샷을 +스토리지클래스(StorageClass)는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를 +설명하는 방법을 제공하는 것처럼, 볼륨스냅샷클래스는 볼륨 스냅샷을 프로비저닝할 때 스토리지의 "클래스"를 설명하는 방법을 제공한다. ## VolumeSnapshotClass 리소스 -각 `VolumeSnapshotClass` 에는 클래스에 속하는 `VolumeSnapshot` 을 +각 볼륨스냅샷클래스에는 클래스에 속하는 볼륨스냅샷을 동적으로 프로비전 할 때 사용되는 `driver`, `deletionPolicy` 그리고 `parameters` 필드를 포함한다. -`VolumeSnapshotClass` 오브젝트의 이름은 중요하며, 사용자가 특정 -클래스를 요청할 수 있는 방법이다. 관리자는 `VolumeSnapshotClass` 오브젝트를 +볼륨스냅샷클래스 오브젝트의 이름은 중요하며, 사용자가 특정 +클래스를 요청할 수 있는 방법이다. 관리자는 볼륨스냅샷클래스 오브젝트를 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가 생성된 이후에는 업데이트할 수 없다. -관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만 -기본 `VolumeSnapshotClass` 를 지정할 수 있다. +```yaml +apiVersion: snapshot.storage.k8s.io/v1beta1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +관리자는`snapshot.storage.kubernetes.io/is-default-class: "true"` 어노테이션을 추가하여 +바인딩할 특정 클래스를 요청하지 않는 볼륨스냅샷에 대한 +기본 볼륨스냅샷클래스를 지정할 수 있다. ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: @@ -52,9 +65,9 @@ parameters: ### 삭제정책(DeletionPolicy) -볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩 된 `VolumeSnapshot` 오브젝트를 삭제할 때 `VolumeSnapshotContent` 의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다. +볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다. -삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 `VolumeSnapshotContent` 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 `VolumeSnapshotContent` 모두 유지된다. +삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 VolumeSnapshotContent 모두 유지된다. ## 파라미터 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index b8ff826d673b3..166fb131506ec 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -23,7 +23,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 ## 배경 도커는 다소 느슨하고, 덜 관리되지만 -[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 +[볼륨](https://docs.docker.com/storage/)이라는 개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 609759906c146..371def5fb8e19 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -861,7 +861,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment ``` Waiting for rollout to finish: 2 of 3 updated replicas are available... deployment.apps/nginx-deployment successfully rolled out -$ echo $? +``` +그리고 `kubectl rollout` 의 종료 상태는 0(success)이다. +```shell +echo $? +``` +``` 0 ``` @@ -1003,7 +1008,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment ``` Waiting for rollout to finish: 2 out of 3 new replicas have been updated... error: deployment "nginx" exceeded its progress deadline -$ echo $? +``` +그리고 `kubectl rollout` 의 종료 상태는 1(error를 의미함)이다. +```shell +echo $? +``` +``` 1 ``` diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index 4f4762fe9d0ed..03083b86edc96 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,7 +1,7 @@ --- title: 가비지(Garbage) 수집 content_type: concept -weight: 60 +weight: 70 --- @@ -10,8 +10,6 @@ weight: 60 소유자가 없는 오브젝트들을 삭제하는 역할을 한다. - - ## 소유자(owner)와 종속(dependent) @@ -170,15 +168,9 @@ kubectl delete replicaset my-repset --cascade=false - ## {{% heading "whatsnext" %}} [디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) [디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) - - - - - diff --git a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/ko/docs/concepts/workloads/controllers/job.md similarity index 100% rename from content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md rename to content/ko/docs/concepts/workloads/controllers/job.md diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index de92b4f3ea26b..99d274a00d935 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -1,7 +1,7 @@ --- title: 완료된 리소스를 위한 TTL 컨트롤러 content_type: concept -weight: 65 +weight: 70 --- @@ -10,7 +10,7 @@ weight: 65 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 -[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만 +{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. @@ -29,7 +29,7 @@ kube-apiserver와 kube-controller-manager와 함께 ## TTL 컨트롤러 현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는 -[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) +[예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리) 와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다. 리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 18f4b3e813fab..470970f284e2b 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -77,7 +77,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 -[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다. +[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. 핸들러에는 다음과 같이 세 가지 타입이 있다. * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core) @@ -406,4 +406,3 @@ spec: - diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 3f30f6eff930c..2c4163ab478ca 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -39,6 +39,7 @@ PR 랭글러의 임무는 다음과 같다. - 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다. - 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다. - PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다. + - 콘텐츠가 문서의 [스타일 가이드라인](/docs/contribute/style/style-guide/) 중 일부만 충족하더라도 정확한 기술 콘텐츠를 수락하는 것이 좋다. 스타일 문제를 해결하기 위해 `good first issue` 라는 레이블로 새로운 이슈를 연다. - 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다. ## 랭글러에게 유용한 GitHub 쿼리 diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 46439d3565ecc..e989f53856010 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -217,21 +217,39 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. -website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. +website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo 컨테이너" %}} +{{< note >}} +아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경변수를 설정한다. +{{< /note >}} + 1. 로컬에서 이미지를 빌드한다. ```bash make docker-image + # docker 사용(기본값) + make container-image + + ### 또는 ### + + # podman 사용 + CONTAINER_ENGINE=podman make container-image ``` 2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. ```bash make docker-serve + # docker 사용(기본값) + make container-serve + + ### 또는 ### + + # podman 사용 + CONTAINER_ENGINE=podman make container-serve ``` 3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index b47bbf5c14846..20377994f1eb1 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -57,6 +57,8 @@ cards: - name: release-notes title: 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. + button: "쿠버네티스 다운로드" + button_path: "/docs/setup/release/notes" - name: about title: 문서에 대하여 description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다. diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md index b0f8342b66f77..453bb6b652206 100755 --- a/content/ko/docs/reference/glossary/cronjob.md +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -11,9 +11,9 @@ tags: - core-object - workload --- - 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/job/)을 관리. -*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://en.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. +*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://ko.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. diff --git a/content/ko/docs/reference/glossary/job.md b/content/ko/docs/reference/glossary/job.md index a2c5a83466dd1..8f227f76ac2d3 100755 --- a/content/ko/docs/reference/glossary/job.md +++ b/content/ko/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: 잡(Job) id: job date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +full_link: /docs/concepts/workloads/controllers/job short_description: > 완료를 목표로 실행되는 유한 또는 배치 작업. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 5d4855386a952..191afaa166ca5 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -286,6 +286,11 @@ kubectl logs -f my-pod # 실시간 스트림 파드 kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우) kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout) kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행 +kubectl run nginx --image=nginx -n +mynamespace # 특정 네임스페이스에서 nginx 파드 실행 +kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록 +--dry-run=client -o yaml > pod.yaml + kubectl attach my-pod -i # 실행중인 컨테이너에 연결 kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달 kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우) diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index 0a4a3fefbeb8d..cf835c5c5cb61 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -8,7 +8,7 @@ card: --- -Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. +Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. 구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. @@ -29,11 +29,11 @@ kubectl [command] [TYPE] [NAME] [flags] * `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` * `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods` @@ -110,13 +110,13 @@ kubectl [command] [TYPE] [NAME] [flags] `version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. `wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. -기억하기: 명령 동작에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ## 리소스 타입 다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. -(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치한다.) +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치했다.) | 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 | |---|---|---|---|---| @@ -172,7 +172,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 출력 옵션 -특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ### 출력 서식화 @@ -231,9 +231,9 @@ kubectl get pods -o custom-columns-file=template.txt NAME RSRC metadata.name metadata.resourceVersion ``` -두 명령 중 하나를 실행한 결과는 다음과 같다. +두 명령 중 하나를 실행한 결과는 다음과 비슷하다. -```shell +``` NAME RSRC submit-queue 610995 ``` @@ -244,7 +244,7 @@ submit-queue 610995 이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다. 이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다. -이 기능은 기본적으로 `kubectl` 1.11 이상에서 활성화되어 있다. 사용하지 않으려면, +이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면, `kubectl get` 명령에 `--server-print=false` 플래그를 추가한다. ##### 예제 @@ -255,9 +255,9 @@ submit-queue 610995 kubectl get pods --server-print=false ``` -출력 결과는 다음과 같다. +출력 결과는 다음과 비슷하다. -```shell +``` NAME AGE pod-name 1m ``` @@ -402,16 +402,20 @@ cat service.yaml | kubectl diff -f - # 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로 # 시작하도록 실행 파일의 이름을 지정한다. cat ./kubectl-hello -#!/bin/bash +``` +```shell +#!/bin/sh # 이 플러그인은 "hello world"라는 단어를 출력한다 echo "hello world" - -# 작성한 플러그인을 실행 가능하게 한다 -sudo chmod +x ./kubectl-hello +``` +작성한 플러그인을 실행 가능하게 한다 +```bash +chmod a+x ./kubectl-hello # 그리고 PATH의 위치로 옮긴다 sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin # 이제 kubectl 플러그인을 만들고 "설치했다". # kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다 @@ -422,16 +426,18 @@ hello world ``` ```shell -# PATH에서 플러그인 파일을 간단히 삭제하여, 플러그인을 "제거"할 수 있다 +# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여, +# 플러그인을 "제거"할 수 있다 sudo rm /usr/local/bin/kubectl-hello ``` `kubectl` 에 사용할 수 있는 모든 플러그인을 보려면, -`kubectl plugin list` 하위 명령을 사용할 수 있다. +`kubectl plugin list` 하위 명령을 사용한다. ```shell kubectl plugin list ``` +출력 결과는 다음과 비슷하다. ``` The following kubectl-compatible plugins are available: @@ -439,11 +445,11 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` + +`kubectl plugin list` 는 또한 실행 가능하지 않거나, +다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다. ```shell -# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, -# 다른 플러그인에 의해 가려진 플러그인에 대해 -# 경고할 수 있다 -sudo chmod -x /usr/local/bin/kubectl-foo +sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거 kubectl plugin list ``` ``` @@ -462,6 +468,10 @@ error: one plugin warning was found ```shell cat ./kubectl-whoami +``` +다음 몇 가지 예는 이미 `kubectl-whoami` 에 +다음 내용이 있다고 가정한다. +```shell #!/bin/bash # 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한 @@ -469,7 +479,7 @@ cat ./kubectl-whoami kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` -위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재 선택된 컨텍스트에 대한 +위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한 사용자가 포함된 출력이 제공된다. ```shell @@ -483,11 +493,10 @@ kubectl whoami Current user: plugins-user ``` -플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. ## {{% heading "whatsnext" %}} -[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. - +* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. +* 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index df95e1dc5cf46..35e3e9a6cb1d5 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -12,9 +12,6 @@ weight: 20 * 전체 컨테이너 300000개 이하 * 노드 당 파드 100개 이하 -
- -{{< toc >}} ## 설치 diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md index 3aa27d96ead86..d4579e2f896f1 100644 --- a/content/ko/docs/setup/best-practices/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -3,7 +3,6 @@ title: 노드 구성 검증하기 weight: 30 --- -{{< toc >}} ## 노드 적합성 테스트 diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index f14834ff25de2..40e4795fb933f 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -62,7 +62,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## 도커 각 머신들에 대해서, 도커를 설치한다. -버전 19.03.8이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. +버전 19.03.11이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 도커 버전의 지속적인 파악이 필요하다. 시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다. @@ -94,9 +94,9 @@ add-apt-repository \ ```shell # 도커 CE 설치. apt-get update && apt-get install -y \ - containerd.io=1.2.13-1 \ - docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) ``` ```shell @@ -142,8 +142,8 @@ yum-config-manager --add-repo \ # 도커 CE 설치. yum update -y && yum install -y \ containerd.io-1.2.13 \ - docker-ce-19.03.8 \ - docker-ce-cli-19.03.8 + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 ``` ```shell @@ -180,6 +180,12 @@ systemctl restart docker {{< /tab >}} {{< /tabs >}} +부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다. + +```shell +sudo systemctl enable docker +``` + 자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/) 를 참고한다. diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index 359ec82a9cd15..8a9425cf13328 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -5,8 +5,6 @@ weight: 50 content_type: concept --- -{{< toc >}} - 쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 @@ -14,67 +12,6 @@ content_type: concept 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다. - - - -## 웹 UI (대시보드) - -쿠버네티스 클러스터에서 컨테이너화 된 애플리케이션을 관리 및 모니터하는 것을 돕기 위해서 대시보드 웹 유저 인터페이스를 디플로이하고 접속한다. - -## kubectl 커맨드라인 사용하기 - -쿠버네티스 클러스터를 직접 관리하기 위해서 사용되는 `kubectl` 커맨드라인 툴을 설치 및 설정한다. - -## 파드 및 컨테이너 구성하기 - -파드 및 컨테이너에 대한 일반적인 구성 태스크를 수행한다. - -## 애플리케이션 동작시키기 - -롤링 업데이트, 파드에 정보 주입하기, 파드 수평적 오토스케일링 등, 일반적인 애플리케이션 관리 태스크를 수행한다. - -## 잡 동작시키기 - -병렬 프로세싱을 사용하는 잡을 동작시킨다. - -## 클러스터의 애플리케이션에 접근하기 - -클러스터 내에 있는 애플리케이션에 접근할 수 있도록 로드 밸런싱, 포트 포워딩, 방화벽 또는 DNS 구성 등을 구성한다. - -## 모니터링, 로깅, 디버깅 - -클러스터 문제를 해결하거나 컨테이너화 된 애플리케이션을 디버깅하기 위해서 모니터링과 로깅을 설정한다. - -## 쿠버네티스 API에 접근하기 - -쿠버네티스 API에 직접 접근하는 다양한 방법을 배운다. - -## TLS 사용하기 - -클러스터 루트 인증 기관(CA)을 신뢰 및 사용하도록 애플리케이션을 구성한다. - -## 클러스터 운영하기(administering) - -클러스터를 운영하기 위한 일반적인 태스크를 배운다. - -## 스테이트풀 애플리케이션 관리하기 - -스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. - -## 클러스터 데몬 - -롤링 업데이트를 수행과 같은, 데몬 셋 관리를 위한 일반적인 태스크를 수행한다. - -## GPU 관리하기 - -클러스터의 노드들에 의해서 리소스로 사용될 NVIDIA GPU들을 구성 및 스케줄한다. - -## HugePage 관리하기 - -클러스터에서 스케줄 가능한 리소스로서 Huge Page들을 구성 및 스케줄한다. - - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tasks/access-application-cluster/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md index 4cb552677c830..603b186517923 100755 --- a/content/ko/docs/tasks/access-application-cluster/_index.md +++ b/content/ko/docs/tasks/access-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "클러스터 내 어플리케이션 액세스" +description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다. weight: 60 --- diff --git a/content/ko/docs/tasks/administer-cluster/_index.md b/content/ko/docs/tasks/administer-cluster/_index.md index 77ca3f2479051..4913ccf73eea3 100755 --- a/content/ko/docs/tasks/administer-cluster/_index.md +++ b/content/ko/docs/tasks/administer-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "클러스터 운영" +description: 클러스터를 운영하기 위한 공통 태스크를 배운다. weight: 20 --- diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 5435bcf67ada7..fed25bc169ae2 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -48,7 +48,7 @@ Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함 간단한 ``올인원`` YAML 파일로 배포할 수 있다. ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` ``` configmap/cilium-config created diff --git a/content/ko/docs/tasks/configure-pod-container/_index.md b/content/ko/docs/tasks/configure-pod-container/_index.md index 560261ecad440..e43910867f3d0 100644 --- a/content/ko/docs/tasks/configure-pod-container/_index.md +++ b/content/ko/docs/tasks/configure-pod-container/_index.md @@ -1,4 +1,5 @@ --- title: "파드와 컨테이너 설정" +description: 파드와 컨테이너에 대한 공통 구성 태스크들을 수행한다. weight: 20 --- diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index 7083bdea675b1..79c3b2390d100 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -25,7 +25,7 @@ weight: 10 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. -Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 +Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화할 수 있다. ```shell @@ -53,7 +53,7 @@ v1beta1.metrics.k8s.io ## 네임스페이스 생성 -이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 +이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다. ```shell @@ -113,7 +113,7 @@ kubectl top pod memory-demo --namespace=mem-example ``` 출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. -이는 파드의 100 MiB 요청 보다 많으나 +이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다. ``` @@ -245,7 +245,7 @@ kubectl delete pod memory-demo-2 --namespace=mem-example 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다. 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는 -컨테이너를 갖는 +컨테이너를 갖는 파드의 구성 파일이다. {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} @@ -344,21 +344,16 @@ kubectl delete namespace mem-example ### 클러스터 관리자들을 위한 -* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/docs/tasks/administer-cluster/memory-default-namespace/) +* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/docs/tasks/administer-cluster/cpu-default-namespace/) - -* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/docs/tasks/administer-cluster/memory-constraint-namespace/) - -* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/docs/tasks/administer-cluster/cpu-constraint-namespace/) - -* [네임스페이스에 메모리 및 CPU 할당량 구성](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) - -* [네임스페이스에 파드 할당량 구성](/docs/tasks/administer-cluster/quota-pod-namespace/) - -* [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/) +* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) +* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) +* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) +* [네임스페이스에 메모리 및 CPU 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) +* [네임스페이스에 파드 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) +* [API 오브젝트에 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/) diff --git a/content/ko/docs/tasks/debug-application-cluster/_index.md b/content/ko/docs/tasks/debug-application-cluster/_index.md index 0613fed1ef989..d0bda0ea0f05c 100755 --- a/content/ko/docs/tasks/debug-application-cluster/_index.md +++ b/content/ko/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "모니터링, 로깅, 그리고 디버깅" +description: 모니터링 및 로깅을 설정하여 클러스터 문제를 해결하거나, 컨테이너화된 애플리케이션을 디버깅한다. weight: 80 --- diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index 1a72dbf241811..d3b06d27034ba 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -1,6 +1,6 @@ --- title: 플러그인으로 kubectl 확장 -description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다. +description: kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다. content_type: task --- diff --git a/content/ko/docs/tasks/inject-data-application/_index.md b/content/ko/docs/tasks/inject-data-application/_index.md index e7ae5375f4748..c5bddeca7e0c0 100644 --- a/content/ko/docs/tasks/inject-data-application/_index.md +++ b/content/ko/docs/tasks/inject-data-application/_index.md @@ -1,5 +1,5 @@ --- title: "애플리케이션에 데이터 주입하기" +description: 워크로드를 실행하는 파드에 대한 구성과 기타 데이터를 지정한다. weight: 30 - ---- \ No newline at end of file +--- diff --git a/content/ko/docs/tasks/manage-daemon/_index.md b/content/ko/docs/tasks/manage-daemon/_index.md index 58b87271c9754..1ff595ef61bd4 100644 --- a/content/ko/docs/tasks/manage-daemon/_index.md +++ b/content/ko/docs/tasks/manage-daemon/_index.md @@ -1,4 +1,5 @@ --- title: "클러스터 데몬 관리" +description: 롤링 업데이트 수행과 같은 데몬셋 관리를 위한 일반적인 작업을 수행한다. weight: 130 --- diff --git a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md index 60aa4f4d1a069..0c79ae8d66aaa 100644 --- a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -2,27 +2,20 @@ title: 데몬셋(DaemonSet)에서 롤백 수행 content_type: task weight: 20 +min-kubernetes-server-version: 1.7 --- - - -이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다. - - +이 페이지는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}에서 롤백을 수행하는 방법을 보여준다. ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은 - 쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다. -* [데몬셋에서 롤링 업데이트를 - 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다. - - - +[데몬셋에서 롤링 업데이트를 + 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 이미 알고 있어야 한다. @@ -40,7 +33,7 @@ kubectl rollout history daemonset 이 명령은 데몬셋 리비전 목록을 반환한다. -```shell +``` daemonsets "" REVISION CHANGE-CAUSE 1 ... @@ -60,17 +53,17 @@ kubectl rollout history daemonset --revision=1 이 명령은 해당 리비전의 세부 사항을 반환한다. -```shell +``` daemonsets "" with revision #1 Pod Template: Labels: foo=bar Containers: app: - Image: ... - Port: ... - Environment: ... - Mounts: ... -Volumes: ... + Image: ... + Port: ... + Environment: ... + Mounts: ... +Volumes: ... ``` ### 2단계: 특정 리비전으로 롤백 @@ -82,16 +75,19 @@ kubectl rollout undo daemonset --to-revision= 성공하면, 명령은 다음을 반환한다. -```shell +``` daemonset "" rolled back ``` -`--to-revision` 플래그를 지정하지 않은 경우, 마지막 리비전이 선택된다. +{{< note >}} +`--to-revision` 플래그를 지정하지 않은 경우, kubectl은 가장 최신의 리비전을 선택한다. +{{< /note >}} ### 3단계: 데몬셋 롤백 진행 상황 확인 `kubectl rollout undo daemonset` 은 서버에 데몬셋 롤백을 시작하도록 -지시한다. 실제 롤백은 서버 측에서 비동기적으로 수행된다. +지시한다. 실제 롤백은 클러스터 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}} +내에서 비동기적으로 수행된다. 롤백 진행 상황을 보려면 다음의 명령을 수행한다. @@ -101,21 +97,17 @@ kubectl rollout status ds/ 롤백이 완료되면, 출력 결과는 다음과 비슷하다. -```shell +``` daemonset "" successfully rolled out ``` - - ## 데몬셋 리비전의 이해 이전 `kubectl rollout history` 단계에서, 데몬셋 리비전 목록을 -얻었다. 각 리비전은 `ControllerRevision` 이라는 리소스에 저장된다. -`ControllerRevision` 은 쿠버네티스 릴리스 1.7 이상에서만 사용할 수 있는 -리소스이다. +얻었다. 각 리비전은 ControllerRevision이라는 리소스에 저장된다. 각 리비전에 저장된 내용을 보려면, 데몬셋 리비전 원시 리소스를 찾는다. @@ -124,30 +116,29 @@ daemonset "" successfully rolled out kubectl get controllerrevision -l = ``` -이 명령은 `ControllerRevisions` 의 목록을 반환한다. +이 명령은 ControllerRevision의 목록을 반환한다. -```shell +``` NAME CONTROLLER REVISION AGE - DaemonSet/ 1 1h - DaemonSet/ 2 1h ``` -각 `ControllerRevision` 은 데몬셋 리비전의 어노테이션과 템플릿을 -저장한다. ControllerRevision 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +각 ControllerRevision은 데몬셋 리비전의 어노테이션과 템플릿을 +저장한다. -`kubectl rollout undo` 는 특정 `ControllerRevision` 을 가져와 데몬셋 -템플릿을 `ControllerRevision` 에 저장된 템플릿으로 바꾼다. +`kubectl rollout undo` 는 특정 ControllerRevision을 가져와 데몬셋 +템플릿을 ControllerRevision에 저장된 템플릿으로 바꾼다. `kubectl rollout undo` 는 `kubectl edit` 또는 `kubectl apply` 와 같은 다른 명령을 통해 데몬셋 템플릿을 이전 리비전으로 업데이트하는 것과 같다. {{< note >}} 데몬셋 리비전은 롤 포워드만 한다. 즉, 롤백이 -완료된 후, 롤백될 `ControllerRevision` 의 +완료된 후, 롤백될 ControllerRevision의 리비전 번호(`.revision` 필드)가 증가한다. 예를 들어, 시스템에 리비전 1과 2가 있고, 리비전 2에서 리비전 1으로 롤백하면, -`ControllerRevision` 은 `.revision: 1` 에서 `.revision: 3` 이 된다. +ControllerRevision은 `.revision: 1` 에서 `.revision: 3` 이 된다. {{< /note >}} ## 문제 해결 @@ -157,4 +148,3 @@ NAME CONTROLLER REVISION AGE - diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 7ea6b51d93eee..dc47a5add9179 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -1,6 +1,7 @@ --- content_type: concept title: GPU 스케줄링 +description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다. --- diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index 9d4e4ca2b38bb..edb0edb08f96d 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -1,16 +1,14 @@ --- title: HugePages 관리 content_type: task +description: 클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다. --- {{< feature-state state="stable" >}} -쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된 -huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 -huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다. - - +쿠버네티스는 파드의 애플리케이션에 미리 할당된 +huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법에 대해 설명한다. ## {{% heading "prerequisites" %}} @@ -118,11 +116,3 @@ glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. - -## 향후 버전 - -- NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다. -- 리밋레인지(LimitRange)를 지원할 예정이다. - - - diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md index 3c6566741c72e..ebb3c90272b1c 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/_index.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/_index.md @@ -1,4 +1,5 @@ --- title: "쿠버네티스 오브젝트 관리" +description: 쿠버네티스 API와 상호 작용하기 위한 선언적이고 명령적인 패러다임 weight: 25 --- diff --git a/content/ko/docs/tasks/network/_index.md b/content/ko/docs/tasks/network/_index.md index 26317241ec603..e7ab0fae52f39 100644 --- a/content/ko/docs/tasks/network/_index.md +++ b/content/ko/docs/tasks/network/_index.md @@ -1,4 +1,5 @@ --- -title: "네트워크" +title: "네트워킹" +description: 클러스터에 대한 네트워킹 설정 방법에 대해 배운다. weight: 160 --- diff --git a/content/ko/docs/tasks/run-application/_index.md b/content/ko/docs/tasks/run-application/_index.md index 203d2eb39c60c..13039181be221 100644 --- a/content/ko/docs/tasks/run-application/_index.md +++ b/content/ko/docs/tasks/run-application/_index.md @@ -1,4 +1,5 @@ --- title: "애플리케이션 실행" +description: 스테이트리스와 스테이트풀 애플리케이션 모두를 실행하고 관리한다. weight: 40 --- 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 bfc602734a7cf..1c04e449421f4 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -181,7 +181,7 @@ CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은 HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. API 오브젝트에 대한 자세한 내용은 -[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다. +[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다. ## kubectl에서 Horizontal Pod Autoscaler 지원 diff --git a/content/ko/docs/tasks/tls/_index.md b/content/ko/docs/tasks/tls/_index.md index 8607aa28d29b6..291b4b3eb171e 100644 --- a/content/ko/docs/tasks/tls/_index.md +++ b/content/ko/docs/tasks/tls/_index.md @@ -1,5 +1,6 @@ --- title: "TLS" +description: TLS(Transport Layer Security)를 사용하여 클러스터 내 트래픽을 보호하는 방법을 이해한다. weight: 100 --- diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 799bc028f6231..bcfcd12e4e14d 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -1,5 +1,6 @@ --- title: "도구 설치" +description: 컴퓨터에서 쿠버네티스 도구를 설정한다. weight: 10 --- diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index 4b498f27ef130..7603a7a5ecb56 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -111,34 +111,34 @@ kubectl version --client 1. 최신 릴리스를 다운로드한다. - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` + ```bash + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ``` - 특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. + 특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. - 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` -2. kubectl 바이너리를 실행 가능하게 만든다. + kubectl 바이너리를 실행 가능하게 만든다. - ``` - chmod +x ./kubectl - ``` + ```bash + chmod +x ./kubectl + ``` 3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다. - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + ``` 4. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### macOS에서 Homebrew를 사용하여 설치 @@ -146,21 +146,21 @@ macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경 1. 설치 명령을 실행한다. - ``` - brew install kubectl - ``` + ```bash + brew install kubectl + ``` - 또는 + 또는 - ``` - brew install kubernetes-cli - ``` + ```bash + brew install kubernetes-cli + ``` 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### macOS에서 Macports를 사용하여 설치 @@ -168,16 +168,16 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하 1. 설치 명령을 실행한다. - ``` - sudo port selfupdate - sudo port install kubectl - ``` + ```bash + sudo port selfupdate + sudo port install kubectl + ``` 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ## Windows에 kubectl 설치 @@ -185,21 +185,21 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하 1. [이 링크](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)에서 최신 릴리스 {{< param "fullversion" >}}을 다운로드한다. - 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. + 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` - 최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다. + 최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다. 2. 바이너리를 PATH가 설정된 디렉터리에 추가한다. 3. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다. - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` {{< note >}} [Windows용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다. @@ -212,20 +212,22 @@ Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다). - ``` - Install-Script -Name install-kubectl -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` + ```powershell + Install-Script -Name install-kubectl -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation ] + ``` -{{< note >}}`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.{{< /note >}} + {{< note >}} + `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다. + {{< /note >}} 설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다. 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` {{< note >}} 설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다. @@ -235,50 +237,54 @@ Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 1. Windows에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. -{{< tabs name="kubectl_win_install" >}} -{{% tab name="choco" %}} - + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell choco install kubernetes-cli - -{{% /tab %}} -{{% tab name="scoop" %}} - + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell scoop install kubectl - -{{% /tab %}} -{{< /tabs >}} + ``` + {{% /tab %}} + {{< /tabs >}} 2. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` 3. 홈 디렉토리로 이동한다. - ``` - cd %USERPROFILE% - ``` + ```powershell + # cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE% + cd ~ + ``` + 4. `.kube` 디렉터리를 생성한다. - ``` - mkdir .kube - ``` + ```powershell + mkdir .kube + ``` 5. 금방 생성한 `.kube` 디렉터리로 이동한다. - ``` - cd .kube - ``` + ```powershell + cd .kube + ``` 6. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다. - ``` - New-Item config -type file - ``` + ```powershell + New-Item config -type file + ``` -{{< note >}}메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.{{< /note >}} +{{< note >}} +메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다. +{{< /note >}} ## Google Cloud SDK의 일부로 다운로드 @@ -288,15 +294,15 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다. 2. `kubectl` 설치 명령을 실행한다. - ``` - gcloud components install kubectl - ``` + ```shell + gcloud components install kubectl + ``` 3. 설치한 버전이 최신 버전인지 확인한다. - ``` - kubectl version --client - ``` + ```shell + kubectl version --client + ``` ## kubectl 구성 확인 @@ -312,7 +318,7 @@ URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르 다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다. -```shell +``` The connection to the server was refused - did you specify the right host or port? ``` @@ -350,7 +356,7 @@ bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](ht 확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다. -```shell +```bash source /usr/share/bash-completion/bash_completion ``` @@ -362,17 +368,17 @@ source /usr/share/bash-completion/bash_completion - `~/.bashrc` 파일에서 완성 스크립트를 소싱한다. - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` - 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다. - ```shell - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다. -```shell +```bash echo 'alias k=kubectl' >>~/.bashrc echo 'complete -F __start_kubectl k' >>~/.bashrc ``` @@ -403,19 +409,19 @@ bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS 여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다. -```shell +```bash echo $BASH_VERSION ``` 너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다. -```shell +```bash brew install bash ``` 셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다. -```shell +```bash echo $BASH_VERSION $SHELL ``` @@ -429,13 +435,13 @@ Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다. bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다. -```shell +```bash brew install bash-completion@2 ``` 이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다. -```shell +```bash export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" ``` @@ -448,29 +454,29 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" - 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다. - ```shell + ```bash echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` - 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다. - ```shell + ```bash kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl ``` - kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 완성을 확장할 수 있다. - ```shell + ```bash echo 'alias k=kubectl' >>~/.bash_profile echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - Homebrew로 kubectl을 설치한 경우([위](#macos에서-homebrew를-사용하여-설치)의 설명을 참고), kubectl 완성 스크립트는 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있어야 한다. 이 경우, 아무 것도 할 필요가 없다. - {{< note >}} - bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다. - {{< /note >}} + {{< note >}} + bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다. + {{< /note >}} 어쨌든, 셸을 다시 로드 한 후에, kubectl 완성이 작동해야 한다. {{% /tab %}} @@ -481,13 +487,13 @@ Zsh용 kubectl 완성 스크립트는 `kubectl completion zsh` 명령으로 생 모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다. -```shell +```zsh source <(kubectl completion zsh) ``` kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다. -```shell +```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` @@ -496,16 +502,13 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc `complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다. -```shell +```zsh autoload -Uz compinit compinit ``` {{% /tab %}} {{< /tabs >}} - - - ## {{% heading "whatsnext" %}} * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/) @@ -513,4 +516,3 @@ compinit * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다. * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기 - diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 4a18224f02275..493d31e95f480 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -70,7 +70,7 @@ content_type: concept 튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 -[내용 페이지 유형](/docs/contribute/style/page-content-types/) +[콘텐츠 페이지 유형](/docs/contribute/style/page-content-types/) 페이지를 참조한다. diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 24405ac955ca9..9790c1f31e1bc 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -44,7 +44,7 @@

요약:

-

kubectl run 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 +

kubectl create deployment 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 디플로이먼트를 만들 수도 있다

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 d384d076556f1..03cfdf88c63d8 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -6,9 +6,9 @@ weight: 10 --- -이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여 -애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드를 생성하고 삭제하며 -스케일링하고 업데이트하는지 시연한다. +이 튜토리얼은 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}}을 이용하여 +애플리케이션을 관리하는 방법을 소개한다. +어떻게 스테이트풀셋의 파드를 생성하고, 삭제하며, 스케일링하고, 업데이트하는지 시연한다. ## {{% heading "prerequisites" %}} @@ -22,13 +22,14 @@ weight: 10 * [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [kubectl CLI](/docs/user-guide/kubectl/) +* [kubectl](/docs/reference/kubectl/kubectl/) 커맨드 라인 도구 +{{< note >}} 이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면, 튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을 프로비저닝해야 한다. - +{{< /note >}} ## {{% heading "objectives" %}} @@ -46,7 +47,6 @@ weight: 10 * 스테이트풀셋은 어떻게 스케일링하는지 * 스테이트풀셋의 파드는 어떻게 업데이트하는지 - ## 스테이트풀셋 생성하기 @@ -74,20 +74,24 @@ kubectl get pods -w -l app=nginx ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` 상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를 -실행하는 2개의 파드를 생성한다. `nginx` 서비스와 -`web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자. +실행하는 2개의 파드를 생성한다. `nginx` 서비스의 정보를 가져온다. ```shell kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None 80/TCP 12s - +``` +그리고 `web` 스테이트풀셋 정보를 가져와서 모두 성공적으로 생성되었는지 확인한다. +```shell kubectl get statefulset web +``` NAME DESIRED CURRENT AGE web 2 1 20s ``` @@ -101,6 +105,8 @@ N개의 레플리카를 가진 스테이트풀셋은 배포 시에 ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -112,8 +118,8 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에 -시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고) +및 _Ready_ ([파드의 조건](/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 @@ -125,16 +131,17 @@ web-1 1/1 Running 0 18s ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 1m web-1 1/1 Running 0 1m - ``` [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. -이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 -고유한 순번에 기인한다. 파드의 이름의 형식은 +이 정체성은 스테이트풀셋 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}에서 +각 파드에 주어지는 고유한 순번에 기인한다. 파드의 이름의 형식은 `<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은 2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다. @@ -145,7 +152,9 @@ web-1 1/1 Running 0 1m [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자. ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` web-0 web-1 ``` @@ -157,7 +166,14 @@ web-1 ```shell kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +위 명령으로 새로운 셸을 시작한다. 새 셸에서 다음을 실행한다. +```shell +# dns-test 컨테이너 셸에서 다음을 실행한다. nslookup web-0.nginx +``` +출력 결과는 다음과 비슷하다. +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -172,6 +188,8 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` +(이제 `exit` 명령으로 컨테이너 셸에서 종료한다.) + 헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다 (Running과 Ready 상태의 각 파드마다 1개). SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다. @@ -196,6 +214,8 @@ pod "web-1" deleted ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -207,15 +227,27 @@ web-1 1/1 Running 0 34s ``` 파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해 -`kubectl exec`과 `kubectl run`을 이용하자. +`kubectl exec`과 `kubectl run`을 이용하자. 먼저, 파드의 호스트네임을 확인한다. ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` web-0 web-1 - +``` +그리고 다음을 실행한다. +``` kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +이 명령으로 새로운 셸이 시작된다. +새 셸에서 다음을 실행한다. +```shell +# dns-test 컨테이너 셸에서 이것을 실행한다. nslookup web-0.nginx +``` +출력 결과는 다음과 비슷하다. +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -230,6 +262,8 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` +(이제 `exit` 명령으로 컨테이너 셸을 종료한다.) + 파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만 파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나 다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로 @@ -255,12 +289,20 @@ Running과 Ready 상태의 모든 파드들을 ```shell kubectl get pvc -l app=nginx +``` +출력 결과는 다음과 비슷하다. +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s ``` -스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 -묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 + +스테이트풀셋 컨트롤러는 2개의 +{{< glossary_tooltip text="퍼시스턴트볼륨" term_id="persistent-volume" >}}에 +묶인 2개의 +{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}을 생성했다. + +본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다. NGINX 웹서버는 기본 색인 파일로 @@ -272,23 +314,23 @@ NGINX 웹서버는 기본 색인 파일로 NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자. ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -it "web-$i" -- curl localhost; done +``` +``` web-0 web-1 ``` {{< note >}} -위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면 -`volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 +위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면 +다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 ([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). -```shell -for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done -``` +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` -위에 curl 명령을 재시도하기 전에 +위에 `curl` 명령을 재시도하기 전에 위 명령을 실행해야 한다. {{< /note >}} 첫째 터미널에서 스테이트풀셋의 파드를 감시하자. @@ -301,6 +343,8 @@ kubectl get pod -w -l app=nginx ```shell kubectl delete pod -l app=nginx +``` +``` pod "web-0" deleted pod "web-1" deleted ``` @@ -309,6 +353,8 @@ pod "web-1" deleted ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -322,7 +368,9 @@ web-1 1/1 Running 0 34s 웹서버에서 자신의 호스트네임을 계속 제공하는지 확인하자. ``` -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` @@ -334,6 +382,7 @@ web-1 각각의 퍼시스턴트볼륨은 적절하게 마운트된다. ## 스테이트풀셋 스케일링 + 스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다. [`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나 [`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을 @@ -352,6 +401,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl scale sts web --replicas=5 +``` +``` statefulset.apps/web scaled ``` @@ -360,6 +411,8 @@ statefulset.apps/web scaled ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2h web-1 1/1 Running 0 2h @@ -392,18 +445,22 @@ web-4 1/1 Running 0 19s kubectl get pods -w -l app=nginx ``` -다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 뒤로 - 3개의 레플리카로 스케일링하자. +다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 다시 +3개의 레플리카로 스케일링하자. ```shell kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` statefulset.apps/web patched ``` `web-4`와 `web-3`이 Terminating으로 전환되기까지 기다리자. -``` +```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3h web-1 1/1 Running 0 3h @@ -428,6 +485,8 @@ web-3 1/1 Terminating 0 42s ```shell kubectl get pvc -l app=nginx +``` +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h @@ -459,6 +518,8 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` statefulset.apps/web patched ``` @@ -467,13 +528,18 @@ statefulset.apps/web patched ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` statefulset.apps/web patched ``` 다른 터미널창에서 스테이트풀셋의 파드를 감시하자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7m web-1 1/1 Running 0 7m @@ -512,17 +578,20 @@ web-0 1/1 Running 0 10s 이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 그것이 Running과 Ready 상태로 전환될 때까지 기다린다. 알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 -다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. +다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 +복원한다는 것이다. + 업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 -이전 버전으로 복원한다. -이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 +이전 버전으로 복원한다. 이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 애플리케이션을 계속 건강하게 유지하고 업데이트도 일관되게 유지하려 한다. 컨테이너 이미지를 살펴보기 위해 파드를 가져오자. ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 @@ -531,10 +600,13 @@ k8s.gcr.io/nginx-slim:0.8 스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다. -**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` +{{< note >}} +스테이트풀셋의 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` 명령어도 사용할 수 있다. +{{< /note >}} #### 단계적으로 업데이트 하기 {#staging-an-update} + `RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여 스테이트풀셋의 단계적으로 업데이트할 수 있다. 단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서 @@ -544,6 +616,8 @@ k8s.gcr.io/nginx-slim:0.8 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` statefulset.apps/web patched ``` @@ -551,20 +625,26 @@ statefulset.apps/web patched ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` statefulset.apps/web patched ``` 스테이트풀셋의 파드를 삭제하자. ```shell -kubectl delete po web-2 +kubectl delete pod web-2 +``` +``` pod "web-2" deleted ``` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -572,12 +652,13 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -파드의 컨테이너를 가져오자. +파드의 컨테이너 이미지를 가져오자. ```shell -kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` 비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은 @@ -586,6 +667,7 @@ k8s.gcr.io/nginx-slim:0.8 `파티션`보다 작기 때문이다. #### 카나리(Canary) 롤링 아웃 + [위에서](#staging-an-update) 지정한 `partition`값을 차감시키면 변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다. @@ -593,13 +675,17 @@ k8s.gcr.io/nginx-slim:0.8 ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` statefulset.apps/web patched ``` `web-2` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -611,6 +697,8 @@ web-2 1/1 Running 0 18s ```shell kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.7 ``` @@ -622,14 +710,19 @@ k8s.gcr.io/nginx-slim:0.7 `web-1` 파드를 삭제하자. ```shell -kubectl delete po web-1 +kubectl delete pod web-1 +``` +``` pod "web-1" deleted ``` `web-1` 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 0/1 Terminating 0 6m @@ -643,12 +736,13 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드의 컨테이너를 가져오자. +`web-1` 파드의 컨테이너 이미지를 가져오자. ```shell -kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` `web-1` 는 원래 환경설정으로 복원되었는데 @@ -658,6 +752,7 @@ k8s.gcr.io/nginx-slim:0.8 종료되어 원래 환경설정으로 복원된다. #### 단계적 롤아웃 + [카나리 롤아웃](#카나리-canary-롤링-아웃)에서 했던 방법과 비슷하게 분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 수행할 수 있다. 단계적 롤아웃을 수행하려면 @@ -668,13 +763,18 @@ partition은 현재 `2`이다. partition을 `0`으로 바꾸자. ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` statefulset.apps/web patched ``` 스테이트풀셋의 모든 파드가 Running과 Ready 상태가 되기까지 기다리자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +출력 결과는 다음과 비슷하다. +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3m web-1 0/1 ContainerCreating 0 11s @@ -692,17 +792,19 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 3s ``` -파드의 컨테이너를 가져오자. +스테이트풀셋에 있는 파드의 컨테이너 이미지 상세 정보를 가져오자. ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 ``` -`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 +`partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서 업데이트 처리를 하도록 허용하였다. ### 삭제 시 동작 @@ -733,6 +835,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web --cascade=false +``` +``` statefulset.apps "web" deleted ``` @@ -740,6 +844,8 @@ statefulset.apps "web" deleted ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 1/1 Running 0 7m @@ -751,6 +857,8 @@ web-2 1/1 Running 0 5m ```shell kubectl delete pod web-0 +``` +``` pod "web-0" deleted ``` @@ -758,6 +866,8 @@ pod "web-0" deleted ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 10m web-2 1/1 Running 0 7m @@ -777,17 +887,21 @@ kubectl get pods -w -l app=nginx ```shell kubectl apply -f web.yaml +``` +``` statefulset.apps/web created service/nginx unchanged ``` 이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도 -nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다. +_nginx_ 헤드리스 서비스를 생성하려고 했음을 뜻한다. 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 16m web-2 1/1 Running 0 2m @@ -813,7 +927,9 @@ web-2 0/1 Terminating 0 3m 다른 관점으로 살펴보자. ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` @@ -837,6 +953,8 @@ kubectl get pods -w -l app=nginx ```shell kubectl delete statefulset web +``` +``` statefulset.apps "web" deleted ``` 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 @@ -844,6 +962,8 @@ statefulset.apps "web" deleted ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 11m web-1 1/1 Running 0 27m @@ -864,12 +984,17 @@ web-1 0/1 Terminating 0 29m 스테이트풀 컨트롤러는 이전 파드가 완전히 종료되기까지 기다린다. -스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를 -삭제하지 않음을 주의하자. +{{< note >}} +종속적 삭제는 파드와 함께 스테이트풀셋을 제거하지만, +스테이트풀셋과 관련된 헤드리스 서비스를 삭제하지 않는다. 꼭 `nginx` 서비스를 수동으로 삭제해라. +{{< /note >}} + ```shell kubectl delete service nginx +``` +``` service "nginx" deleted ``` @@ -877,6 +1002,8 @@ service "nginx" deleted ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -885,22 +1012,30 @@ statefulset.apps/web created `index.html` 파일 내용을 검색하자. ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` 스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로 -다시 생성되고 `web-0`과 `web-1`은 여전히 +다시 생성되고 `web-0`과 `web-1`은 계속 각 호스트네임을 제공한다. -최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다. +최종적으로 `web` 스테이트풀셋을 삭제한다. ```shell kubectl delete service nginx +``` +``` service "nginx" deleted - +``` +그리고 `nginx` 서비스를 삭제한다. +```shell kubectl delete statefulset web +``` +``` statefulset "web" deleted ``` @@ -934,13 +1069,15 @@ statefulset "web" deleted 터미널에서 스테이트풀셋의 파드를 감시하자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w ``` 다른 터미널에서 매니페스트 안에 스테이트풀셋과 서비스를 생성하자. ```shell kubectl apply -f web-parallel.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -948,7 +1085,9 @@ statefulset.apps/web created 첫째 터미널에서 실행했던 `kubectl get` 명령어의 출력을 살펴보자. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -967,12 +1106,14 @@ web-1 1/1 Running 0 10s ```shell kubectl scale statefulset/web --replicas=4 +``` +``` statefulset.apps/web scaled ``` `kubectl get` 명령어를 실행 중인 터미널의 출력을 살펴보자. -```shell +``` web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 7s @@ -982,18 +1123,24 @@ web-3 1/1 Running 0 26s ``` -스테이트풀 컨트롤러는 두 개의 새 파드를 시작하였다. +스테이트풀셋은 두 개의 새 파드를 시작하였다. 두 번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 때까지 기다리지 않는다. -이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자. +## {{% heading "cleanup" %}} + +정리의 일환으로 `kubectl` 명령을 실행할 준비가 된 두 개의 터미널이 열려 +있어야 한다. ```shell kubectl delete sts web +# sts는 statefulset의 약자이다. ``` -다시 한번 다른 터미널에서 실행 중인 `kubectl get`명령의 출력을 확인해보자. - +`kubectl get` 명령으로 해당 파드가 삭제된 것을 확인할 수 있다. ```shell +kubectl get pod -l app=nginx -w +``` +``` web-3 1/1 Terminating 0 9m web-2 1/1 Terminating 0 9m web-3 1/1 Terminating 0 9m @@ -1019,7 +1166,7 @@ web-3 0/1 Terminating 0 9m web-3 0/1 Terminating 0 9m ``` -스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에 +삭제하는 동안, 스테이트풀셋은 모든 파드를 동시에 삭제한다. 해당 파드를 삭제하기 전에 그 파드의 순서상 후계자를 기다리지 않는다. `kubectl get` 명령어가 실행된 터미널을 닫고 @@ -1030,12 +1177,11 @@ kubectl delete svc nginx ``` -## {{% heading "cleanup" %}} - +{{< note >}} 이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 -퍼시스턴트 스토리지 미디어를 삭제해야 한다. -모든 스토리지를 반환하도록 환경, 스토리지 설정과 -프로비저닝 방법에 따른 단계를 따르자. - +퍼시스턴트 스토리지 미디어도 삭제해야 한다. +모든 스토리지를 반환하도록 환경, 스토리지 설정과 +프로비저닝 방법에 따른 단계를 따르자. +{{< /note >}} diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 323a087408988..1e0aefd4a3601 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -190,8 +190,8 @@ kubectl apply -k ./ 응답은 아래와 비슷해야 한다. ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 80:32406/TCP 4m ``` {{< note >}} @@ -237,7 +237,7 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. -* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. +* [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자. * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. diff --git a/content/ko/partners/_index.html b/content/ko/partners/_index.html index 2ac7e6945c839..3bd6a375f2311 100644 --- a/content/ko/partners/_index.html +++ b/content/ko/partners/_index.html @@ -7,79 +7,90 @@ ---
-
-
쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.
-
-
-
-
- 공인 쿠버네티스 서비스 공급자(Kubernetes Certified Service Providers, KCSP) -
-
기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다. -


- -

KCSP에 관심이 있으신가요? -
-
-
-
-
- 공인 쿠버네티스 배포, 호스트된 플랫폼 그리고 설치 프로그램 -
소프트웨어 적합성은 모든 벤더의 쿠버네티스 버전이 필요한 API를 지원하도록 보장합니다. -


- -

공인 쿠버네티스에 관심이 있으신가요? -
-
-
-
-
쿠버네티스 교육 파트너(Kubernetes Training Partners, KTP)
-
클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다. -



- -

KTP에 관심이 있으신가요? -
-
-
- - + - -
- - -
- -
+ + +
+ + +
+ +