From 33719dc80cb910e3aff16a20de6dd82718c46585 Mon Sep 17 00:00:00 2001 From: power8993 <37264128+power8993@users.noreply.github.com> Date: Sat, 23 Nov 2019 13:29:49 +0900 Subject: [PATCH] Sixth Korean l10n work for release-1.16 * Update _index.md (#17762) * Update apparmor.md (#17767) * Update hello-minikube.md (#17771) * Update guestbook.md (#17773) * Update localization_ko.md (#17777) * Fix grammatical errors (#17776) * Translate /docs/reference/issues-security/security.md in Korea (#17763) * Create issues.md (#17765) * Update basic-stateful-set.md (#17774) * Fixed typo ko/docs/concepts/overview/components.md (#17778) * Modify typo. (#17802) * Update cloud-controller.md (#17760) * Update file outdated korean docs in dev-1.16-ko.6. (#17772) * Translate concepts/services-networking/ingress-controller in Korean (#17858) * Update ingress-controller.md * Translate services-networking/ingress.md in Korean. (#17807) * Fix grammatical errors (#17775) * Translate docs/contribute/style/write-new-topic.md in Korean (#17758) Co-Authored-By: const-k Co-Authored-By: Yuk, Yongsu Co-Authored-By: power8993 <37264128+power8993@users.noreply.github.com> Co-Authored-By: reung37 <49059415+reung37@users.noreply.github.com> Co-Authored-By: Chihoon-Sung <55041611+Chihoon-Sung@users.noreply.github.com> Co-Authored-By: Claudia J.Kang Co-Authored-By: Seokho Son --- content/ko/docs/concepts/_index.md | 6 +- .../concepts/architecture/cloud-controller.md | 3 +- .../ko/docs/concepts/architecture/nodes.md | 1 - .../ko/docs/concepts/overview/components.md | 25 +- .../concepts/overview/what-is-kubernetes.md | 2 +- .../overview/working-with-objects/labels.md | 5 + .../services-networking/endpoint-slices.md | 8 +- .../ingress-controllers.md | 61 +++ .../concepts/services-networking/ingress.md | 477 ++++++++++++++++++ .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/deployment.md | 2 +- content/ko/docs/contribute/_index.md | 8 +- content/ko/docs/contribute/localization_ko.md | 1 + .../docs/contribute/style/write-new-topic.md | 167 ++++++ .../docs/reference/issues-security/issues.md | 13 + .../reference/issues-security/security.md | 53 ++ content/ko/docs/setup/_index.md | 3 +- .../setup/learning-environment/minikube.md | 2 +- .../production-environment/tools/kops.md | 2 +- .../windows/user-guide-windows-nodes.md | 6 +- .../access-cluster.md | 26 +- .../web-ui-dashboard.md | 2 +- .../horizontal-pod-autoscale-walkthrough.md | 2 +- .../ko/docs/tasks/tools/install-minikube.md | 10 +- .../ko/docs/templates/feature-state-beta.txt | 2 +- .../ko/docs/tutorials/clusters/apparmor.md | 44 +- content/ko/docs/tutorials/hello-minikube.md | 10 +- .../ko/docs/tutorials/services/source-ip.md | 4 +- .../basic-stateful-set.md | 42 +- .../mysql-wordpress-persistent-volume.md | 4 +- .../stateful-application/zookeeper.md | 32 +- .../stateless-application/guestbook.md | 14 +- .../examples/service/networking/ingress.yaml | 9 + 33 files changed, 913 insertions(+), 135 deletions(-) create mode 100644 content/ko/docs/concepts/services-networking/ingress-controllers.md create mode 100644 content/ko/docs/concepts/services-networking/ingress.md create mode 100644 content/ko/docs/contribute/style/write-new-topic.md create mode 100644 content/ko/docs/reference/issues-security/issues.md create mode 100644 content/ko/docs/reference/issues-security/security.md create mode 100644 content/ko/examples/service/networking/ingress.yaml diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index b46ac7f593dc0..d6643ec3a46c3 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -17,7 +17,7 @@ weight: 40 쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다. -바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator (PLEG) 를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다. +바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다. * **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다. * 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다. @@ -59,10 +59,6 @@ weight: 40 클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다. -#### 오브젝트 메타데이터 - - -* [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) {{% /capture %}} diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index 4bdef8c662fd6..ac298f9dc3d9a 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -83,7 +83,7 @@ CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급 #### 서비스 컨트롤러 -서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucutre LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다. +서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucuture LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다. ### 2. Kubelet @@ -231,6 +231,7 @@ rules: * [Linode](https://github.com/linode/linode-cloud-controller-manager) * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) * [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) ## 클러스터 관리 diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index d800263154cb2..e2a3813ec6d05 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -48,7 +48,6 @@ kubectl describe node | Node Condition | Description | |----------------|-------------| -| `OutOfDisk` | 노드 상에 새로운 파드를 추가하기 위한 여유 공간이 부족할 경우 `True`, 반대의 경우 `False` | | `Ready` | 노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 `True`, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 `False`, 그리고 노드 컨트롤러가 마지막 `node-monitor-grace-period` (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) `Unknown` | | `MemoryPressure` | 노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 `True`, 반대의 경우 `False` | | `PIDPressure` | 프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 `True`, 반대의 경우 `False` | diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 65f4c6b7f2748..c8cea19b9d7ee 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -13,15 +13,20 @@ card: 이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한 다양한 컴포넌트들에 대해 요약하고 정리한다. + +여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다. + +![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.png) + {{% /capture %}} {{% capture body %}} ## 마스터 컴포넌트 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정 -(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동 시키는 것)를 감지하고 반응한다. +(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다. -마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나, +마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고, 사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면 [고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다. @@ -63,11 +68,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 * 노드 컨트롤러: 노드가 응답을 멈추고 나서 클라우드 상에서 삭제되어 졌는지 확정하기 위해 클라우드 제공사업자에게 확인하는 것 * 라우트 컨트롤러: 바탕을 이루는 클라우드 인프라에 경로를 구성하는 것 * 서비스 컨트롤러: 클라우드 제공사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것 - * 볼륨 컨트롤러: 볼륨의 생성, 부착 그리고 마운트 하는 것과 볼륨을 조정하기 위해 클라우드 제공사업자와 상호작용 하는 것 + * 볼륨 컨트롤러: 볼륨의 생성, 부착 그리고 마운트 하는 것과 볼륨을 조정하기 위해 클라우드 제공사업자와 상호작용하는 것 ## 노드 컴포넌트 -노드 컴포넌트는 동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다. +노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다. ### kubelet @@ -88,30 +93,30 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 이용하여 클러스터 기능을 구현한다. 이들은 클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다. -선택된 일부 애드온은 아래에 설명하였고, 사용가능한 전체 확장 애드온 리스트는 +선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. ### DNS -여타 애드온들이 절대적으로 요구되지 않는 반면에, 많은 예시들에서 그것을 필요로 하기때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다. +여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 그것을 필요로 하기 때문에 모든 쿠버네티스 클러스터는 [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 갖추어야만 한다. 클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다. -쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함시킨다. +쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다. ### 웹 UI (대시보드) -[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자로 하여금 클러스터 자체 뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다. +[대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 고장처리를 할 수 있도록 허용해준다. ### 컨테이너 리소스 모니터링 [컨테이너 리소스 모니터링](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은 -중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다. +중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다. ### 클러스터-레벨 로깅 [클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 -검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다. +검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다. {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 771422f4d07fa..569a3cef273e7 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -74,7 +74,7 @@ card: * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다. -* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. +* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. * 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 1a207f42a4c16..41fc2df1cd8ef 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -89,6 +89,11 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충되는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. {{< /note >}} +{{< caution >}} +일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. +필터 구문이 적절히 구성되어있는지 확인해야 한다. +{{< /caution >}} + ### _일치성 기준_ 요건 _일치성 기준_ 또는 _불일치 기준_ 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만 레이블의 명시된 제약 조건을 모두 만족해야 한다. diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 9ad714860d42b..4f0354e9e1b4d 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -58,12 +58,12 @@ endpoints: ``` 기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트 슬라이스에는 -각각 100개 이하의 엔드포인트가 가지고 있다. 이 스케일 아래에서 엔드포인트 슬라이스는 -엔드포인트 및 서비스와 1:1 매핑해야하며, 유사한 성능을 가져야 한다. +각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트 슬라이스는 +엔드포인트 및 서비스와 1:1로 매핑해야하며, 유사한 성능을 가져야 한다. 엔드포인트 슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에 -신뢰할 수 있는 소스로 작용할 수 있다. 활성화 하면, 많은 수의 엔드포인트를 가지는 -서비스에 대해 성능 향상을 제공한다. +신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는 +서비스에 대해 성능 향상을 제공해야 한다. ## 사용동기 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md new file mode 100644 index 0000000000000..b2a5e4f723e0f --- /dev/null +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -0,0 +1,61 @@ +--- +title: 인그레스 컨트롤러 +reviewers: +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다. + +kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. +클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다. + +프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와 + [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다. + +{{% /capture %}} + +{{% capture body %}} + +## 추가 컨트롤러 + +* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 + [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 + [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. +* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. +* [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다. +* [Contour](https://projectcontour.io/)는 VMware에서 제공하고 지원하는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. +* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. +* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. +* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다. +* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다. +* [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다. +* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 + [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). +* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. +* [NGINX, Inc.](https://www.nginx.com/) 는 [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. +* 쿠버네티스 인그레스와 같이 사용 사례를 포함하는 서비스 구성을 위한 [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. +* [Traefik](https://github.com/containous/traefik)은 완벽한 기능([암호화](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. + +## 여러 인그레스 컨트롤러 사용 + +하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. 인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 어떤 인그레스 컨트롤러를 사용해야하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 어노테이션을 각각의 인그레스에 달아야 한다. + +만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다. + +이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다. + +{{< note >}} +인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다. +{{< /note >}} + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [인그레스](/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. +* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). + +{{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md new file mode 100644 index 0000000000000..6ee517af750ed --- /dev/null +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -0,0 +1,477 @@ +--- +title: 인그레스 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +{{< feature-state for_k8s_version="v1.1" state="beta" >}} +{{< glossary_definition term_id="ingress" length="all" >}} +{{% /capture %}} + +{{% capture body %}} + +## 용어 + +이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. + +노드(Node) +: 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. + +클러스터(Cluster) +: 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. + +에지 라우터(Edge router) +: 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. + +클러스터 네트워크(Cluster network) +: 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. + +서비스(Service) +: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. + +## 인그레스란? + +인그레스는 클러스터 외부에서 클러스터 내부 +{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다. +트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. + +```none + internet + | + [ Ingress ] + --|-----|-- + [ Services ] +``` + +인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. + +인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 +[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. + +## 전제 조건들 + +[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다. + +[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러 +[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다. + +이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스 +컨트롤러는 조금 다르게 작동한다. + +{{< note >}} +인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야 한다. +{{< /note >}} + +## 인그레스 리소스 + +최소한의 인그레스 리소스 예제: + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: test-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - http: + paths: + - path: /testpath + backend: + serviceName: test + servicePort: 80 +``` + + 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. + 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. + 인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데, + 그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다. + 다른 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다. + 지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다. + +인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) +에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은, +들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP 트래픽을 +지시하는 규칙만 지원한다. + +### 인그레스 규칙 + +각 HTTP 규칙에는 다음의 정보가 포함된다. + +* 선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드 + HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예, + foo.bar.com), 규칙이 해당 호스트에 적용된다. +* 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련 + 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가 + 모두 수신 요청의 내용과 일치해야 한다. +* 백엔드는 [서비스 문서](/docs/concepts/services-networking/service/)에 설명된 바와 같이 + 서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한 + HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다. + +기본 백엔드는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스 +컨트롤러에 구성되는 경우가 많다. + +### 기본 벡엔드 + +규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본 +백엔드는 일반적으로 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다. + +만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은 +기본 백엔드로 라우팅 된다. + +## 인그레스 유형들 + +### 단일 서비스 인그레스 + +단일 서비스를 노출할 수 있는 기존 쿠버네티스 개념이 있다 +([대안](#대안)을 본다). 인그레스에 규칙 없이 *기본 백엔드* 를 지정해서 +이를 수행할 수 있다. + +{{< codenew file="service/networking/ingress.yaml" >}} + +만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의 +상태를 볼 수 있어야 한다. + +```shell +kubectl get ingress test-ingress +``` + +``` +NAME HOSTS ADDRESS PORTS AGE +test-ingress * 107.178.254.228 80 59s +``` + +여기서 `107.178.254.228` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 +할당한 IP 이다. + +{{< note >}} +인그레스 컨트롤러와 로드 밸런서는 IP 주소를 할당하는데 1~2분이 걸릴 수 있다. +할당될 때 까지는 주소는 종종 `` 으로 표시된다. +{{< /note >}} + +### 간단한 팬아웃(fanout) + +팬아웃 구성은 HTTP URI에서 요청된 것을 기반으로 단일 IP 주소에서 1개 이상의 서비스로 +트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를 +최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다. + +```none +foo.bar.com -> 178.91.123.132 -> / foo service1:4200 + / bar service2:8080 +``` + +다음과 같은 인그레스가 필요하다. + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: simple-fanout-example + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - host: foo.bar.com + http: + paths: + - path: /foo + backend: + serviceName: service1 + servicePort: 4200 + - path: /bar + backend: + serviceName: service2 + servicePort: 8080 +``` + +`kubectl apply -f` 를 사용해서 인그레스를 생성 할 때 다음과 같다. + +```shell +kubectl describe ingress simple-fanout-example +``` + +``` +Name: simple-fanout-example +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo service1:4200 (10.8.0.90:4200) + /bar service2:8080 (10.8.0.91:8080) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 22s loadbalancer-controller default/test +``` + +인그레스 컨트롤러는 서비스(`service1`, `service2`)가 존재하는 한, +인그레스를 만족시키는 특정한 로드 밸런서를 프로비저닝한다. +이렇게 하면, 주소 필드에서 로드 밸런서의 주소를 +볼 수 있다. + +{{< note >}} +사용중인 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) +에 따라 default-http-backend +[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다. +{{< /note >}} + +### 이름 기반의 가상 호스팅 + +이름 기반의 가상 호스트는 동일한 IP 주소에서 여러 호스트 이름으로 HTTP 트래픽을 라우팅하는 것을 지원한다. + +```none +foo.bar.com --| |-> foo.bar.com service1:80 + | 178.91.123.132 | +bar.foo.com --| |-> bar.foo.com service2:80 +``` + +다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을 +라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다. + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: name-virtual-host-ingress +spec: + rules: + - host: foo.bar.com + http: + paths: + - backend: + serviceName: service1 + servicePort: 80 + - host: bar.foo.com + http: + paths: + - backend: + serviceName: service2 + servicePort: 80 +``` + +만약 규칙에 정의된 호스트 없이 인그레스 리소스를 생성하는 경우, +이름 기반 가상 호스트가 없어도 인그레스 컨트롤러의 IP 주소에 대한 웹 +트래픽을 일치 시킬 수 있다. + +예를 들어, 다음 인그레스 리소스는 `first.bar.com`에 요청된 트래픽을 +`service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지 +않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든 +트래픽은 `service3`로 라우팅 한다. + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: name-virtual-host-ingress +spec: + rules: + - host: first.bar.com + http: + paths: + - backend: + serviceName: service1 + servicePort: 80 + - host: second.foo.com + http: + paths: + - backend: + serviceName: service2 + servicePort: 80 + - http: + paths: + - backend: + serviceName: service3 + servicePort: 80 +``` + +### TLS + +TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}} +을 지정해서 인그레스를 보호할 수 있다. 현재 인그레스는 +단일 TLS 포트인 443만 지원하며 TLS 종료를 가정한다. 만약 인그레스의 TLS +구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해 +지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱 +된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는 +`tls.crt` 와 `tls.key` 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와 +개인 키가 있다. 예를 들어 다음과 같다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: testsecret-tls + namespace: default +data: + tls.crt: base64 encoded cert + tls.key: base64 encoded key +type: kubernetes.io/tls +``` + +인그레스에서 시크릿을 참조하면 인그레스 컨트롤러가 TLS를 사용하여 +클라이언트에서 로드 밸런서로 채널을 보호하도록 지시한다. 생성한 +TLS 시크릿이 `sslexample.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고 +하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다. + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: tls-example-ingress +spec: + tls: + - hosts: + - sslexample.foo.com + secretName: testsecret-tls + rules: + - host: sslexample.foo.com + http: + paths: + - path: / + backend: + serviceName: service1 + servicePort: 80 +``` + +{{< note >}} +TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능 +차이가 있다. 사용자 환경에서의 TLS의 작동 방식을 이해하려면 +[nginx](https://git.k8s.io/ingress-nginx/README.md#https), +[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) 또는 기타 +플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다. +{{< /note >}} + +### 로드밸런싱 + +인그레스 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 구성표 등 +모든 인그레스에 적용되는 일부 로드 밸런싱 +정책 설정으로 부트스트랩된다. 보다 진보된 로드 밸런싱 개념 +(예: 지속적인 세션, 동적 가중치)은 아직 인그레스를 통해 +노출되지 않는다. 대신 서비스에 사용되는 로드 밸런서를 통해 이러한 기능을 +얻을 수 있다. + +또한, 헬스 체크를 인그레스를 통해 직접 노출되지 않더라도, 쿠버네티스에는 +[준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)와 +같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이 +있다는 점도 주목할 가치가 있다. 컨트롤러 별 +설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다( +[nginx](https://git.k8s.io/ingress-nginx/README.md), +[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)). + +## 인그레스 업데이트 + +기존 인그레스를 업데이트해서 새 호스트를 추가하려면, 리소스를 편집해서 호스트를 업데이트 할 수 있다. + +```shell +kubectl describe ingress test +``` + +``` +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo service1:80 (10.8.0.90:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 35s loadbalancer-controller default/test +``` + +```shell +kubectl edit ingress test +``` + +YAML 형식의 기존 구성이 있는 편집기가 나타난다. +새 호스트를 포함하도록 수정한다. + +```yaml +spec: + rules: + - host: foo.bar.com + http: + paths: + - backend: + serviceName: service1 + servicePort: 80 + path: /foo + - host: bar.baz.com + http: + paths: + - backend: + serviceName: service2 + servicePort: 80 + path: /foo +.. +``` + +변경사항을 저장한 후, kubectl은 API 서버의 리소스를 업데이트하며, 인그레스 +컨트롤러에게도 로드 밸런서를 재구성하도록 지시한다. + +이것을 확인한다. + +```shell +kubectl describe ingress test +``` + +``` +Name: test +Namespace: default +Address: 178.91.123.132 +Default backend: default-http-backend:80 (10.8.2.3:8080) +Rules: + Host Path Backends + ---- ---- -------- + foo.bar.com + /foo service1:80 (10.8.0.90:80) + bar.baz.com + /foo service2:80 (10.8.0.91:80) +Annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ADD 45s loadbalancer-controller default/test +``` + +수정된 인그레스 YAML 파일을 `kubectl replace -f` 를 호출해서 동일한 결과를 얻을 수 있다. + +## 가용성 영역에 전체에서의 실패 + +장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다. +자세한 내용은 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2) +를 참조할 수 있다. + +## 앞으로의 할일 + +[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) +를 추적하여 인그레스와 진행중인 리소스의 발전에 대한 자세한 내용을 알아 본다. 다양한 +인그레스 컨트롤러의 발전에 대한 자세한 내용은 +[인그레스 리포지터리](https://github.com/kubernetes/ingress/tree/master)에서 추적할 수 있다. + +## 대안 + +사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다. + +* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 사용. +* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 사용. + +{{% /capture %}} + +{{% capture whatsnext %}} +* [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 +* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index dbeb1fb643deb..023bc74bc8b77 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. - 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 7c012196d542b..c79b13bc48c45 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1143,7 +1143,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 ### kubectl 롤링 업데이트 -[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)도 +[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)도 비슷한 방식으로 파드와 레플리케이션 컨트롤러를 업데이트한다. 그러나 디플로이먼트는 선언적이고, 서버 측면이며, 롤링 업데이트가 완료된 후에도 이전 수정 버전으로 롤백하는 것과 같은 추가 기능을 가지고 있으므로 권장한다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index a97c5b1c6dcf5..b954a3478e747 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -10,8 +10,8 @@ weight: 80 쿠버네티스 문서 또는 웹사이트에 기여하여 도움을 제공하고 싶다면, 우리는 당신의 도움을 기쁘게 생각한다! 당신이 새로운 프로젝트에 참여했거나 -오랜 시간 동안 진행해온 누군가로써, -혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로써 기여할 수 있다. +오랜 시간 동안 진행해온 누군가로서, +혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로서 기여할 수 있다. 쿠버네티스 문서 내용과 스타일에 대해 더 많은 정보를 알고 싶다면, @@ -26,7 +26,7 @@ weight: 80 멤버십 자격에 대한 구체적인 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참고하라. - SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서 - SIG Docs 승안자가 적합한 + SIG Docs 승인자가 적합한 GitHub 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한 쿠버네티스 조직의 멤버이다. - SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다. @@ -42,7 +42,7 @@ weight: 80 그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는 일로 나누어졌다. 지속적으로 기여를 하는 것은 이미 만들어진 도구(tooling)와 조직의 결정을 -이해하는데 도움이 될 것이다. +이해하는 데 도움이 될 것이다. 이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만, 시작하는 데에 도움이 될 것이다. diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 0b5c5ed837968..d3f058e65e611 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -193,6 +193,7 @@ Instance group | 인스턴스 그룹 | introspection | 인트로스펙션(introspection) | Istio | 이스티오(Istio) | Job | 잡 | +kube-proxy | kube-proxy | Kubelet | Kubelet | Kubernetes | 쿠버네티스 | label | 레이블 | diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md new file mode 100644 index 0000000000000..3fafd55addbe2 --- /dev/null +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -0,0 +1,167 @@ +--- +title: 새로운 주제의 문서 작성 +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} +이 페이지는 쿠버네티스 문서에서 새로운 주제를 생성하는 방법을 보여준다. +{{% /capture %}} + +{{% capture prerequisites %}} +[기여 시작하기](/docs/contribute/start/)에 설명된 대로 쿠버네티스 +문서 저장소의 포크(fork)를 생성하자. +{{% /capture %}} + +{{% capture steps %}} + +## 페이지 타입 선택 + +새로운 주제 작성을 준비할 때는, 콘텐츠에 가장 적합한 페이지 타입을 고려하자. + +{{< table caption = "페이지 타입 선택 지침" >}} +타입 | 설명 +:--- | :---------- +개념 | 개념 페이지는 쿠버네티스의 일부 측면을 설명한다. 예를 들어 개념 페이지는 쿠버네티스 디플로이먼트 오브젝트를 설명하고 배치, 확장 및 업데이트되는 동안 애플리케이션으로서 수행하는 역할을 설명할 수 있다. 일반적으로 개념 페이지는 일련의 단계가 포함되지 않지만 대신 태스크나 튜토리얼에 대한 링크를 제공한다. 개념 문서의 예로서 노드를 참조하자. +태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 저장소에 볼륨을 사용하도록 파드 구성을 참조하자. 더 긴 태스크 페이지의 예제는 활동성 및 준비성 프로브 구성을 참조하자. +튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다. +{{< /table >}} + +새 페이지에 대한 템플릿을 사용하자. 각 페이지 타입에 있는 +[템플릿](/docs/contribute/style/page-templates/) +은 문서를 작성할 때 사용할 수 있다. 템플릿을 사용하면 +지정된 타입의 문서 간에 일관성을 보장할 수 있다. + +## 제목과 파일 이름 선택 + +검색 엔진에서 찾을 키워드가 있는 제목을 선택하자. +제목에 있는 단어를 하이픈으로 구분하여 사용하는 파일 이름을 만들자. +예를 들어 +[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +이라는 제목의 문서는 `http-proxy-access-api.md`라는 이름의 파일을 가진다. +"쿠버네티스"가 이미 해당 주제의 URL에 있기 때문에 파일 이름에 "쿠버네티스" 를 넣을 필요가 없다. +예를 들면 다음과 같다. + + /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + +## 전문에 항목 제목 추가 + +문서에서 [전문](https://gohugo.io/content-management/front-matter/) +에 `제목` 필드를 입력하자. +전문은 페이지 상단의 3중 점선 사이에 있는 +YAML 블록이다. 여기 예시가 있다. + + --- + 제목: HTTP 프록시를 사용하여 쿠버네티스 API에 접근 + --- + +## 디렉토리 선택 + +페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉토리에 넣자. + +* /content/en/docs/tasks/ +* /content/en/docs/tutorials/ +* /content/en/docs/concepts/ + +파일을 기존 하위 디렉토리에 넣거나 새 하위 디렉토리에 +넣을 수 있다. + +## 목차에 항목 배치 + +목차는 문서 소스의 디렉토리 구조를 사용하여 +동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉토리는 최상위 레벨 탐색 기능을 +생성하고, 하위 디렉토리는 각각 목차에 항목을 +갖는다. + +각 하위 디렉토리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉토리의 컨텐츠에 대한 +"홈" 페이지를 나타낸다. `_index.md`에는 템플릿이 필요없다. 그것은 +하위 디렉토리의 항목에 대한 개요 내용을 포함할 수 있다. + +디렉토리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의 +최적의 순서가 아니다. 하위 디렉토리에서 항목의 상대적 정렬을 제어하려면 +`가중치:` 전문의 키를 정수로 설정하자. 일반적으로 우리는 +나중에 항목을 추가하기 위해 10의 배수를 사용한다. 예를 들어 가중치가 +`10`인 항목은 가중치가 `20`인 항목보다 우선한다. + +## 문서에 코드 포함 + +문서에 코드를 포함시키려면 마크다운 코드 블록 구문을 사용하여 +파일에 코드를 직접 삽입하자. 다음 경우에 +권장된다. (전체 목록은 아님) + +- 이 코드는 `kubectl get deploy mydeployment -o json | jq '.status'`와 같은 + 명령어의 출력을 보여준다. +- 이 코드는 시도해보기에 적절하지 않다. 예를 들어 + 특정 [FlexVolume](/docs/concepts/storage/volumes#flexvolume) 구현에 따라 + 파드를 만들기 위해 YAML 파일을 + 포함할 수 있다. +- 이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에 + 불완전한 예제다. 예를 들어 몇 가지 이유로 + [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy) + 를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다. +- 이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어 + `kubectl edit` 명령을 사용하여 리소스에 새 속성을 추가하는 방법을 + 설명할 때 추가할 만한 속성을 포함하는 + 간단한 예를 제공할 수 있다. + +## 다른 파일의 코드 포함 + +문서에 코드를 포함시키는 또 다른 방법은 새로운 완전한 샘플 파일 +(또는 샘플 파일 그룹)을 만든 다음 문서의 샘플을 참조하는 것이다. +일반적이고 재사용 가능하며 독자가 스스로 실행해 볼 수 있도록 하는 +샘플 YAML 파일을 포함시키려면 이 방법을 사용하자. + +YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때 +`/examples/` 의 하위 디렉토리 중 하나에 코드를 배치하자. 여기서 ``은 +주제에 관한 언어이다. 문서 파일에서 `codenew` 단축 코드(shortcode)를 사용하자. + +
{{< codenew file="<RELPATH>/my-example-yaml>" >}}
+ +여기서 `` 는 `examples` 디렉토리와 관련하여 포함될 +파일의 경로이다. 다음 Hugo 단축 코드(shortcode)는 `/content/en/examples/pods/storage/gce-volume.yaml` +에 있는 YAML 파일을 참조한다. + +```none +{{}} +``` + +{{< note >}} +위의 예와 같은 원시 Hugo 단축 코드(shortcode)를 표시하고 Hugo가 +해석하지 못하게 하려면 `<` 문자 바로 다음과 `>` 문자 앞에 C 스타일 주석을 사용하자. +그 예로서 이 페이지의 코드를 확인하자. +{{< /note >}} + +## 구성 파일에서 API 오브젝트를 작성하는 방법 표시 + +구성 파일을 기반으로 API 오브젝트를 생성하는 방법을 보여주려면 +`/examples` 아래의 하위 디렉토리 중 하나에 +구성 파일을 배치하자. + +문서에서 이 명령을 띄워보자. + +``` +kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml +``` + +{{< note >}} +`/examples` 디렉토리에 새 YAMl 파일을 추가할 때 파일이 +`/examples_test.go` 파일에도 포함되어 있는지 확인하자. +웹 사이트의 Travis CI 는 PR이 제출될 때 이 예제를 자동으로 +실행하여 모든 예제가 테스트를 통과하도록 한다. +{{< /note >}} + +이 기술을 사용하는 문서의 예로 +[단일 인스턴스 스테이트풀 어플리케이션 실행](/docs/tutorials/stateful-application/run-stateful-application/)을 참조하자. + +## 문서에 이미지 추가 + +이미지 파일을 `/images` 디렉토리에 넣는다. 기본 +이미지 형식은 SVG 이다. + +{{% /capture %}} + +{{% capture whatsnext %}} +* [페이지 템플릿 사용](/docs/home/contribute/page-templates/)에 대해 알아보기. +* [변경 사항 준비](/docs/home/contribute/stage-documentation-changes/)에 대해 알아보기. +* [풀 리퀘스트 작성](/docs/home/contribute/create-pull-request/)에 대해 알아보기. +{{% /capture %}} diff --git a/content/ko/docs/reference/issues-security/issues.md b/content/ko/docs/reference/issues-security/issues.md new file mode 100644 index 0000000000000..83d5f87f52436 --- /dev/null +++ b/content/ko/docs/reference/issues-security/issues.md @@ -0,0 +1,13 @@ +--- +title: 쿠버네티스 이슈 트래커 +weight: 10 +aliases: [/cve/,/cves/] +--- + +보안 문제를 보고하려면 [쿠버네티스 보안 공개 프로세스](/docs/reference/issues-security/security/#report-a-vulnerability)를 따른다. + +쿠버네티스 코드 작업 및 공개 이슈는 [깃허브 이슈](https://github.com/kubernetes/kubernetes/issues/)를 사용하여 추적된다. + +* [CVE-연관된 이슈들](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) + +보안에 관련된 공지사항은 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 메일 리스트로 전송된다. diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md new file mode 100644 index 0000000000000..6ae7a27fc38a4 --- /dev/null +++ b/content/ko/docs/reference/issues-security/security.md @@ -0,0 +1,53 @@ +--- +title: 쿠버네티스 보안과 공개 정보 +aliases: [/security/] +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} +이 페이지는 쿠버네티스 보안 및 공개 정보를 설명한다. +{{% /capture %}} + +{{% capture body %}} +## 보안 공지 + +보안 및 주요 API 공지에 대한 이메일을 위해 [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) 그룹에 가입하세요. + +[이 링크](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다. + +## 취약점 보고 + +우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다. + +보고서를 작성하기 위해서는 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로부터 예상되는 세부 사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다. + +[제품 보안 위원회 구성원](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc)의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다. + +### 언제 취약점을 보고해야 하는가? + +- 쿠버네티스에서 잠재적인 보안 취약점을 발견했다고 생각하는 경우 +- 취약성이 쿠버네티스에 어떤 영향을 미치는지 확신할 수 없는 경우 +- 쿠버네티스가 의존하는 다른 프로젝트에서 취약점을 발견한 경우 + - 자체 취약성 보고 및 공개 프로세스가 있는 프로젝트의 경우 직접 보고한다. + + +### 언제 취약점을 보고하지 말아야 하는가? + +- 보안을 위해 쿠버네티스 구성요소를 조정하는데 도움이 필요한 경우 +- 보안 관련 업데이트를 적용하는 데 도움이 필요한 경우 +- 보안 관련 문제가 아닌 경우 + +## 보안 취약점 대응 + +각 보고서는 제품 보안 위원회 위원들에 의해 작업일 3일 이내에 인정되고 분석된다. 이렇게 하면 [보안 릴리스 프로세스](https://git.k8s.io/security/security-release-process.md#disclosures)가 시작된다. + +제품 보안 위원회와 공유하는 모든 취약성 정보는 쿠버네티스 프로젝트 내에 있으며, 문제를 해결할 필요가 없는 한 다른 프로젝트에 전파되지 않는다. + +보안 문제가 심사에서 확인된 수정, 릴리스 계획으로 이동함에 따라 리포터를 계속 업데이트할 것이다. + +## 공개 시기 + +공개 날짜는 쿠버네티스 제품 보안 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지입니다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 제품 보안 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다. +{{% /capture %}} + diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index c50b7d33141d7..50928ca6e1f8d 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -79,7 +79,7 @@ card: | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ | [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ | [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ -| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ (via OpenStack) | ✔ | | +| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [사용자 정의 확장](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | | [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | @@ -94,6 +94,7 @@ card: | [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | | [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | | [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | +| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | | | [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | | | [oVirt](https://www.ovirt.org/) | | | | | ✔ | diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index e213113f7d3f3..d9fce5275fc6c 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -199,7 +199,7 @@ minikube start --vm-driver= * hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) 다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. * vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) -* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))) +* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 개인용 워크스테이션에서 none 드라이버를 사용하는 것을 권장하지 않는다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))) #### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index ccc47579b73aa..5a2438dc8e089 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -52,7 +52,7 @@ Linux에서: ```shell wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64 chmod +x kops-linux-amd64 -mv kops-linux-amd64 /usr/local/bin/kops +sudo mv kops-linux-amd64 /usr/local/bin/kops ``` ### (2/5) 클러스터에 사용할 route53 domain 생성 diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md index ad4c7dc0ee9ed..e57da7dfd12dd 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md @@ -251,7 +251,7 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes 1. 컨테이너와 쿠버네티스를 설치 (시스템 재시작 필요) -기존에 내려받은[KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/KubeCluster.ps1) 스크립트를 사용해서 쿠버네티스를 윈도우 서버 컨테이너 호스트에 설치한다. +기존에 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1) 스크립트를 사용해서 쿠버네티스를 윈도우 서버 컨테이너 호스트에 설치한다. ```PowerShell .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -install @@ -282,7 +282,7 @@ v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes 이 섹션에서는 클러스터를 구성하기 위해서 [쿠버네티스가 설치된 윈도우 노드](#윈도우-노드-준비하기)를 기존의 (리눅스) 컨트롤 플레인에 참여시키는 방법을 다룬다. -앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/KubeCluster.ps1) 스크립트를 사용해서 윈도우 노드를 클러스터에 참여시킨다. +앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1) 스크립트를 사용해서 윈도우 노드를 클러스터에 참여시킨다. ```PowerShell .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -join @@ -317,7 +317,7 @@ kubectl get nodes #### 윈도우 노드를 쿠버네티스 클러스터에서 제거하기 이 섹션에서는 윈도우 노드를 쿠버네티스 클러스터에서 제거하는 방법을 다룬다. -앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/KubeCluster.ps1) 스크립트를 사용해서 클러스터에서 윈도우 노드를 제거한다. +앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1) 스크립트를 사용해서 클러스터에서 윈도우 노드를 제거한다. ```PowerShell .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -reset diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index a1690412133ad..8566e1d15101c 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -68,7 +68,7 @@ IPv6 주소 [::1]로도 대체할 수 있다. curl http://localhost:8080/api/ ``` -결과값은 다음과 같을 것이다. +결괏값은 다음과 같을 것이다. ```json { @@ -155,8 +155,8 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터 ### Go 클라이언트 -* 라이브러리를 취득하려면 `go get k8s.io/client-go//kubernetes` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다. -* client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 import "k8s.io/client-go/1.4/pkg/api/v1"로 import하는 것을 예로 들 수 있다. +* 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다. +* client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다. Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. @@ -210,7 +210,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 액세스 -이전 장은 쿠버네티스 API server 접속에 대한 내용들을 다루었다. 이번 장은 +이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 [노드들](/docs/admin/node), [파드들](/docs/user-guide/pods), [서비스들](/docs/user-guide/services)은 모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 @@ -219,14 +219,14 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ### 통신을 위한 방식들 -클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는데는 몇 가지 선택지들이 있다. +클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다. - 공인 IP를 통해 서비스에 액세스. - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용한다. [서비스](/docs/user-guide/services)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출시키거나 - 인터넷으로 노출시킬 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 + 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. 해당 서비스는 자체적으로 인증을 수행하는가? - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. @@ -234,7 +234,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 액세스할 필요는 없다. - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스. - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출시키기에 보안이 충분하지 않거나 노드 IP 상의 port에 + 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다. - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. - HTTP/HTTPS에서만 동작한다. @@ -255,7 +255,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. kubectl cluster-info ``` -결과값은 다음과 같을 것이다. +결괏값은 다음과 같을 것이다. ``` Kubernetes master is running at https://104.197.5.247 @@ -316,7 +316,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 - 구성하는 client side javascript를 가진 web app은 동작되지 않을 수 있다. + 구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다. ## 요청 redirect @@ -342,8 +342,8 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - apiserver process들 내에서 실행된다 - proxy하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http) - 타겟으로의 proxy는 가용정보를 사용하는 proxy에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다 - - 노드, 파드, 서비스에 접근하는데 사용될 수 있다 - - 서비스에 접근하는데 사용되면 load balacing한다 + - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다 + - 서비스에 접근하는 데 사용되면 load balacing한다 1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): @@ -351,7 +351,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - UDP와 TCP를 proxy한다 - HTTP를 인지하지 않는다 - load balancing을 제공한다 - - 서비스에 접근하는데만 사용된다 + - 서비스에 접근하는 데만 사용된다 1. apiserver(s) 전면의 Proxy/Load-balancer: diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index b3f436f0bc184..0764ea2e90d5c 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -26,7 +26,7 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta6/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index e23cfd4cb52e9..b97f9384606b4 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -104,7 +104,7 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 ```shell -kubectl run -i --tty load-generator --image=busybox /bin/sh +kubectl run --generator=run-pod/v1 -it --rm load-generator --image=busybox /bin/sh Hit enter for command prompt diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 5b87bb9640f97..cc35e5449ff80 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -75,7 +75,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) {{< note >}} -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않는다. none 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 에서 도커를 apt로 설치하기를 사용하는 것을 권장한다. 도커의 스냅 설치는 minikube에서 작동하지 않는다. {{< /note >}} ### 패키지를 이용하여 Minikube 설치 @@ -186,19 +186,19 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{% /capture %}} -## 새롭게 시작하기 위해 모두 정리하기 +## 새롭게 시작하기 위해 모두 정리하기 {#cleanup-local-state} -이전에 minikube를 설치했었다면, 다음을 실행한다. +이전에 Minikube를 설치했었다면, 다음을 실행한다. ```shell minikube start ``` -그리고 이 명령은 에러를 보여준다. +그리고 `minikube start`는 에러를 보여준다. ```shell machine does not exist ``` -구성 파일을 삭제해야 한다. +이제 구성 파일을 삭제해야 한다. ```shell minikube delete ``` diff --git a/content/ko/docs/templates/feature-state-beta.txt b/content/ko/docs/templates/feature-state-beta.txt index 948ac1ccdb6fa..0314381585de2 100644 --- a/content/ko/docs/templates/feature-state-beta.txt +++ b/content/ko/docs/templates/feature-state-beta.txt @@ -1,7 +1,7 @@ 이 기능은 현재 *베타(beta)* 상태로, 다음을 의미한다. * 버전 이름에는 베타(예: v2beta3)가 포함된다. -* 코드의 테스트가 완료 되었다. 기능을 활성화 해도 안전한 것으로 간주된다. 기본으로 활성화 되어 있다. +* 코드의 테스트가 완료되었다. 기능을 활성화해도 안전한 것으로 간주한다. 기본으로 활성화되어 있다. * 자세한 내용은 변경될 수 있지만, 전체 기능에 대한 지원은 중단되지 않는다. * 오브젝트의 스키마 및(또는) 의미(semantics)는 후속 베타 또는 안정적인 릴리즈에서 호환되지 않는 방식으로 변경될 수 있다. 이 경우, 다음 버전으로 마이그레이션하기 위한 지침을 제공할 것이다. 이를 위해서는 API 오브젝트의 삭제, 수정 또는 재생성이 필요할 수 있다. 편집 과정에서 약간의 생각이 필요할 수 있다. 이 기능을 사용하는 애플리케이션은 가동 중지 시간(downtime)이 필요할 수 있다. * 후속 릴리즈에서 호환되지 않는 변경 가능성이 있으므로 오직 업무상 중요하지 않은 용도로만 권장한다. 만약 사용자가 독립적으로 업그레이드가 가능한 다중 클러스터를 가지고 있다면, 이 제약은 완화될 수 있다. diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 6ca7617c5e87c..858bb59f58d1a 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -11,9 +11,9 @@ content_template: templates/tutorial AppArmor는 표준 리눅스 사용자와 그룹 기반의 권한을 보완하여, 한정된 리소스 집합으로 프로그램을 제한하는 리눅스 커널 보안 모듈이다. AppArmor는 임의의 애플리케이션에 대해서 -잠재적인 공격범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다. +잠재적인 공격 범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다. 이 기능은 특정 프로그램이나 컨테이너에서 필요한 리눅스 기능, 네트워크 사용, 파일 권한 등에 대한 -접근 허용 목록를 조정한 프로파일로 구성한다. 각 프로파일은 +접근 허용 목록 조정한 프로파일로 구성한다. 각 프로파일은 허용하지 않은 리소스 접근을 차단하는 *강제(enforcing)* 모드 또는 위반만을 보고하는 *불평(complain)* 모드로 실행할 수 있다. @@ -27,7 +27,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 {{% capture objectives %}} -* 노드에 프로파일을 어떻게 적재 하는지 예시를 본다. +* 노드에 프로파일을 어떻게 적재하는지 예시를 본다. * 파드(Pod)에 프로파일을 어떻게 강제 적용하는지 배운다. * 프로파일이 적재되었는지 확인하는 방법을 배운다. * 프로파일을 위반하는 경우를 살펴본다. @@ -54,7 +54,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 ``` 2. AppArmor 커널 모듈을 사용 가능해야 한다. -- 리눅스 커널에 AppArmor 프로파일을 강제 적용하기 위해 AppArmor 커널 모듈은 반드시 설치되어 있고 - 사용 가능해야 한다. 예를 들어 Ubnutu 및 SUSE 같은 배포판은 모듈을 기본값으로 지원하고, 그 외 많은 다른 배포판들은 선택적으로 지원한다. + 사용 가능해야 한다. 예를 들어 Ubuntu 및 SUSE 같은 배포판은 모듈을 기본값으로 지원하고, 그 외 많은 다른 배포판들은 선택적으로 지원한다. 모듈이 사용 가능한지 확인하려면 `/sys/module/apparmor/parameters/enabled` 파일을 확인한다. @@ -63,8 +63,8 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 Y ``` - Kubelet(>=v1.4)이 AppArmor 기능 지원을 포함하지만 커널 모듈을 사용할 수 없으면 - 파드에서 AppArmor 옵션을 실행하는 것을 거부된다. + Kubelet(>=v1.4)이 AppArmor 기능 지원을 포함하지만, 커널 모듈을 사용할 수 없으면 + 파드에서 AppArmor 옵션을 실행하는 것이 거부된다. {{< note >}} 우분투에는 추가적인 훅(hook)이나 추가 기능 패치를 포함한 리눅스 커널의 상위 스트림에 머지되지 않은 @@ -72,21 +72,11 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 상위 스트림 버전에서 테스트한 패치만을 가지고 있어서 다른 기능은 지원을 보장하지 않는다. {{< /note >}} -3. 컨테이너 런타임이 도커이다. -- 이는 현재 쿠버네티스에서 지원하는 컨테이너 런타임이며 AppArmor도 지원한다. - 더 많은 런타임에서 AppArmor 지원을 추가할수록 설정은 확장될 것이다. - 노드가 도커로 운영되고 있는지 확인할 수 있다. - - ```shell - $ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}' - ``` - ``` - gke-test-default-pool-239f5d02-gyn2: docker://1.11.2 - gke-test-default-pool-239f5d02-x1kf: docker://1.11.2 - gke-test-default-pool-239f5d02-xwux: docker://1.11.2 - ``` - - Kubelet(>=v1.4)은 AppArmor 지원을 포함하지만, 도커 런타임이 아니라면 - 파드를 AppArmor 옵션으로 실행하는 것은 거부된다. +3. 컨테이너 런타임이 AppArmor을 지원한다. -- 현재 모든 일반적인 쿠버네티스를 지원하는 +{{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="cri-o" >}} 또는 +{{< glossary_tooltip term_id="containerd" >}} 와 같은 컨테이너 런타임들은 AppArmor를 지원해야 한다. +이 런타임 설명서를 참조해서 클러스터가 AppArmor를 사용하기 위한 +요구 사항을 충족하는지 확인해야 한다. 4. 프로파일이 적재되어 있다. -- AppArmor는 각 컨테이너와 함께 실행해야 하는 AppArmor 프로파일을 지정하여 파드에 적용한다. 커널에 지정한 프로파일이 적재되지 않았다면, Kubelet(>= v1.4)은 파드를 거부한다. 해당 노드에 어떤 프로파일이 적재되었는지는 @@ -132,7 +122,7 @@ AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한 [일반 사용자 버전으로 업그레이드 방법](#upgrade-path-to-general-availability) 참고) {{< /note >}} -AppArmor 프로파일은 *컨테이너 마다* 지정된다. 함께 실행할 파드 컨테이너에 AppArmor 프로파일을 지정하려면 +AppArmor 프로파일은 *컨테이너마다* 지정된다. 함께 실행할 파드 컨테이너에 AppArmor 프로파일을 지정하려면 파드의 메타데이터에 어노테이션을 추가한다. ```yaml @@ -341,7 +331,7 @@ Events: * 각 노드에서 파드를 실행하는 [데몬셋](/docs/concepts/workloads/controllers/daemonset/)을 통해서 올바른 프로파일이 적재되었는지 확인한다. 예시 구현은 - [여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아 볼 수 있다. + [여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아볼 수 있다. * 노드 초기화 시간에 노드 초기화 스크립트(예를 들어 Salt, Ansible 등)나 이미지를 이용 * [예시](#example)에서 보여준 것처럼, @@ -403,13 +393,13 @@ AppArmor가 일반 사용자 버전이 되면 제거된다. AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다. 모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니 전환이 필요할 때에 상세히 설명할 것이다. -최소 두번의 릴리즈에 대해서는 필드와 어노테이션 모두를 지원할 것이고, +최소 두 번의 릴리즈에 대해서는 필드와 어노테이션 모두를 지원할 것이고, 그 이후부터는 어노테이션은 명확히 거부된다. ## 프로파일 제작 {#authoring-profiles} AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까다로울 수 있다. -다행히 이 작업에 도움되는 도구가 있다. +다행히 이 작업에 도움 되는 도구가 있다. * `aa-genprof`와 `aa-logprof`는 애플리케이션 활동과 로그와 수행에 필요한 행동을 모니터링하여 일반 프로파일 규칙을 생성한다. 자세한 사용방법은 @@ -422,7 +412,7 @@ AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까 파드가 실행 중인 쿠버네티스 노드에서 도구 실행을 금하지는 않는다. AppArmor 문제를 디버깅하기 위해서 거부된 것으로 보이는 시스템 로그를 확인할 수 있다. -AppArmor 로그는 `dmesg`에서 보여지며, 오류는 보통 시스템 로그나 +AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 `journalctl`에서 볼 수 있다. 더 많은 정보는 [AppArmor 실패](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)에서 제공한다. @@ -443,7 +433,7 @@ AppArmor 로그는 `dmesg`에서 보여지며, 오류는 보통 시스템 로그 - `runtime/default`: 기본 런타임 프로파일을 참조한다. - (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고 AppArmor를 사용하는 것과 동등하다. - - 도커에서는 권한없는 컨테이너의 경우는 + - 도커에서는 권한 없는 컨테이너의 경우는 [`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로, 권한이 있는 컨테이너의 경우 unconfined(프로파일 없음)으로 해석한다. - `localhost/`: 노드(localhost)에 적재된 프로파일을 이름으로 참조한다. diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index b359bc309d2a6..1e76acf3d0407 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -20,7 +20,7 @@ card: Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. {{< note >}} -[로컬에서 Minikube](/ko/docs/tasks/tools/install-minikube/)를 설치했다면 이 튜토리얼도 따라할 수 있다. +[로컬에서 Minikube](/ko/docs/tasks/tools/install-minikube/)를 설치했다면 이 튜토리얼도 따라 할 수 있다. {{< /note >}} {{% /capture %}} @@ -127,13 +127,13 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 외부에서 접근하려면 파드를 쿠버네티스 [*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다. -1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출시키기 +1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출하기 ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출시키기 + `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기 원한다는 뜻이다. 2. 방금 생성한 서비스 살펴보기 @@ -255,13 +255,13 @@ kubectl delete service hello-node kubectl delete deployment hello-node ``` -필요시 Minikube 가상 머신(VM)을 정지한다. +필요하면 Minikube 가상 머신(VM)을 정지한다. ```shell minikube stop ``` -필요시 minikube VM을 삭제한다. +필요하면 minikube VM을 삭제한다. ```shell minikube delete diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index f6654f58911e4..cdc430dc1bced 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -245,7 +245,7 @@ client_address=10.240.0.5 ``` 그러나 구글 클라우드 엔진/GCE 에서 실행 중이라면 동일한 `service.spec.externalTrafficPolicy` 필드를 `Local`로 설정하면 -서비스 엔드포인트가 *없는* 노드는 고의적으로 헬스 체크에 실패하여 +서비스 엔드포인트가 *없는* 노드는 고의로 헬스 체크에 실패하여 강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서 자신을 스스로 제거한다. @@ -308,7 +308,7 @@ __크로스 플랫폼 지원__ 쿠버네티스 1.5부터 Type=LoadBalancer 서비스를 통한 소스 IP 주소 보존을 지원하지만, -이는 클라우드 공급자(GCE, Azure)의 하위 집합으로 구현되어 있다. 실행중인 클라우드 공급자에서 +이는 클라우드 공급자(GCE, Azure)의 하위 집합으로 구현되어 있다. 실행 중인 클라우드 공급자에서 몇 가지 다른 방법으로 로드밸런서를 요청하자. 1. 클라이언트 연결을 종료하고 새 연결을 여는 프록시를 이용한다. 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 8adc83eafbf02..e204e94df3d68 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -66,7 +66,7 @@ weight: 10 kubectl get pods -w -l app=nginx ``` -두번째 터미널에서 +두 번째 터미널에서 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로 `web.yaml`에 정의된 헤드리스 서비스와 스테이트풀셋을 생성한다. @@ -92,7 +92,7 @@ web 2 1 20s ### 차례대로 파드 생성하기 -N개의 레플리카를 가진 스테이트풀셋은 배포시에 +N개의 레플리카를 가진 스테이트풀셋은 배포 시에 순차적으로 {0..N-1} 순으로 생성된다. 첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자. 결국 그 내용은 아래 예와 비슷할 것이다. @@ -179,7 +179,7 @@ SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지 ```shell kubectl get pod -w -l app=nginx ``` -두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해 +두 번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기 위해 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를 이용하자. @@ -234,7 +234,7 @@ Address 1: 10.244.2.8 스테이트풀셋의 파드에 접속하지 않도록 하는 것이 중요하다. -스테이트풀셋의 활성 맴버를 찾아 연결할 경우 +스테이트풀셋의 활성 멤버를 찾아 연결할 경우 헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다. CNAME과 연관된 SRV 레코드는 스테이트풀셋의 Running과 Ready 상태의 모든 파드들을 @@ -295,15 +295,15 @@ for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done kubectl get pod -w -l app=nginx ``` -두번째 터미널에서 스테이트풀셋의 모든 파드를 삭제하자. +두 번째 터미널에서 스테이트풀셋의 모든 파드를 삭제하자. ```shell kubectl delete pod -l app=nginx pod "web-0" deleted pod "web-1" deleted ``` -첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, -모든 파드가 Running과 Ready 상태로 전환될때까지 기다리자. +첫 번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, +모든 파드가 Running과 Ready 상태로 전환될 때까지 기다리자. ```shell kubectl get pod -w -l app=nginx @@ -353,8 +353,8 @@ kubectl scale sts web --replicas=5 statefulset.apps/web scaled ``` -첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, -3개의 추가 파드가 Running과 Ready 상태로 전환될때까지 기다리자. +첫 번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, +3개의 추가 파드가 Running과 Ready 상태로 전환될 때까지 기다리자. ```shell kubectl get pods -w -l app=nginx @@ -379,7 +379,7 @@ web-4 1/1 Running 0 19s 스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다. [스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는 각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에 -이전 파드가 Running과 Ready 상태가 될때까지 +이전 파드가 Running과 Ready 상태가 될 때까지 기다린다. ### 스케일 다운 {#scaling-down} @@ -418,7 +418,7 @@ web-3 1/1 Terminating 0 42s ### 순차 파드 종료 -컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고 +컨트롤러는 순번의 역순으로 한 번에 1개 파드를 삭제하고 다음 파드를 삭제하기 전에 각각이 완전하게 종료되기까지 기다린다. @@ -508,7 +508,7 @@ web-0 1/1 Running 0 10s 스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다. 이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 -그것이 Running과 Ready 상태로 전환될때까지 기다린다. +그것이 Running과 Ready 상태로 전환될 때까지 기다린다. 알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. 업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 @@ -703,7 +703,7 @@ k8s.gcr.io/nginx-slim:0.7 `partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 업데이트 처리를 하도록 허용하였다. -### 삭제시 동작 +### 삭제 시 동작 `OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로, 이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의 @@ -769,7 +769,7 @@ web-2 1/1 Running 0 7m kubectl get pods -w -l app=nginx ``` -두번째 터미널에서 스테이트풀셋을 다시 생성하자. +두 번째 터미널에서 스테이트풀셋을 다시 생성하자. `nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를 볼 것이라는 것을 명심하자. @@ -800,7 +800,7 @@ web-2 0/1 Terminating 0 3m web-2 0/1 Terminating 0 3m ``` -`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다. +`web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다. `web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로 전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 `web-0`을 재생성했다면 `web-1`이 @@ -816,7 +816,7 @@ web-0 web-1 ``` -스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던 +스테이트풀셋과 `web-0` 파드를 둘 다 삭제했으나 여전히 `index.html` 파일에 입력했던 원래 호스트네임을 제공한다. 스테이트풀셋은 파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다. 다시 스테이트풀셋을 생성하면 `web-0`을 시작하며 @@ -838,7 +838,7 @@ kubectl delete statefulset web statefulset.apps "web" deleted ``` 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 -모든 파드가 Terminating 상태로 전환될때까지 기다리자. +모든 파드가 Terminating 상태로 전환될 때까지 기다리자. ```shell kubectl get pods -w -l app=nginx @@ -958,9 +958,9 @@ web-0 1/1 Running 0 10s web-1 1/1 Running 0 10s ``` -스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘다 동시에 시작했다. +스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘 다 동시에 시작했다. -두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을 +두 번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을 스케일링 하자. ```shell @@ -980,8 +980,8 @@ web-3 1/1 Running 0 26s ``` -스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다. -두번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 떄까지 기다리지 않는다. +스테이트풀 컨트롤러는 두 개의 새 파드를 시작하였다. +두 번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 때까지 기다리지 않는다. 이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자. 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 991d43262cede..71919aad75586 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 @@ -15,7 +15,7 @@ card: [퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다. {{< warning >}} -이 배포는 프로덕션 사용예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자. +이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자. {{< /warning >}} {{< note >}} @@ -221,7 +221,7 @@ kubectl apply -k ./ {{% capture cleanup %}} -1. 다음 명령을 실핼하여 시크릿, 디플로이먼트, 서비스와 퍼시스턴트볼륨클레임을 삭제하자. +1. 다음 명령을 실행하여 시크릿, 디플로이먼트, 서비스와 퍼시스턴트볼륨클레임을 삭제하자. ```shell kubectl delete -k ./ diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index f541864416de5..27d5fa90cf09a 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -13,7 +13,7 @@ weight: 40 {{% capture prerequisites %}} -이 튜토리얼을 시작하지 전에 +이 튜토리얼을 시작하기 전에 다음 쿠버네티스 개념에 친숙해야 한다. - [파드](/docs/user-guide/pods/single-container/) @@ -26,7 +26,7 @@ weight: 40 - [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) - [kubectl CLI](/docs/user-guide/kubectl/) -최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시적으로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 주는 혼란이 발생하지 않도록 해야합니다. +최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. 이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다. 그렇게 설정되어 있지 않다면 @@ -38,7 +38,7 @@ weight: 40 이 튜토리얼을 마치면 다음에 대해 알게 된다. - 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가. -- 어떻게 지속적으로 컨피그맵을 이용해서 앙상블을 설정하는가. +- 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가. - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가. - 어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가. {{% /capture %}} @@ -55,7 +55,7 @@ ZooKeeper는 데이터를 읽고 쓰고 갱신을 지켜보도록 한다. 데이 [Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) 합의 프로토콜을 이용하여 앙상블 내에 모든 서버에 걸쳐 상태 머신을 복제하여 이를 보장한다. -앙상블은 리더 선출을 위해 Zab 프로토콜을 사용하고, 리더 선출과 선거가 완료되기 전까지 앙상블은 데이터를 쓸 수 없다. 완료되면 앙상블은 Zab을 이용하여 확인하고 클라이언트에 보여지도록 모든 쓰기를 쿼럼(quorum)에 복제한다. 가중치있는 쿼럼과 관련없이, 쿼럼은 현재 리더를 포함하는 앙상블의 대다수 컴포넌트이다. 예를 들어 앙상블이 3개 서버인 경우, 리더와 다른 서버로 쿼럼을 구성한다. 앙상블이 쿼럼을 달성할 수 없다면, 앙상블은 데이터를 쓸 수 없다. +앙상블은 리더 선출을 위해 Zab 프로토콜을 사용하고, 리더 선출과 선거가 완료되기 전까지 앙상블은 데이터를 쓸 수 없다. 완료되면 앙상블은 Zab을 이용하여 확인하고 클라이언트에 보이도록 모든 쓰기를 쿼럼(quorum)에 복제한다. 가중치있는 쿼럼과 관련 없이, 쿼럼은 현재 리더를 포함하는 앙상블의 대다수 컴포넌트이다. 예를 들어 앙상블이 3개 서버인 경우, 리더와 다른 서버로 쿼럼을 구성한다. 앙상블이 쿼럼을 달성할 수 없다면, 앙상블은 데이터를 쓸 수 없다. ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변이를 저장 미디어의 내구성 있는 WAL(Write Ahead Log)에 기록한다. 서버 장애시 WAL을 재생하여 이전 상태를 복원할 수 있다. WAL이 무제한으로 커지는 것을 방지하기 위해 ZooKeeper는 주기적으로 저장 미디어에 메모리 상태의 스냅샷을 저장한다. 이 스냅샷은 메모리에 직접 적재할 수 있고 스냅샷 이전의 모든 WAL 항목은 삭제될 수 있다. @@ -507,7 +507,7 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n ``` -이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다. 표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다. 또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰여진 로그로 인하여 로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다. +이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다. 표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다. 또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여 로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다. 파드의 마지막 20줄의 로그를 가져오는 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) 명령을 이용하자. @@ -515,7 +515,7 @@ log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %- kubectl logs zk-0 --tail 20 ``` -`kubectl logs`를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰여진 애플리케이션 로그를 볼 수 있다. +`kubectl logs`를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰인 애플리케이션 로그를 볼 수 있다. ```shell 2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740 @@ -546,11 +546,11 @@ kubectl logs zk-0 --tail 20 클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 [사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다. -### 권한없는 사용자를 위해 구성하기 +### 권한 없는 사용자를 위해 구성하기 컨테이너 내부의 권한있는 유저로 애플리케이션을 실행할 수 있도록 하는 최상의 방법은 논쟁거리이다. -조직에서 애플리케이션을 권한없는 사용자가 실행한다면, +조직에서 애플리케이션을 권한 없는 사용자가 실행한다면, 진입점을 실행할 사용자를 제어하기 위해 [시큐리티컨텍스트](/docs/tasks/configure-pod-container/security-context/)를 이용할 수 있다. @@ -632,7 +632,7 @@ Waiting for 1 pods to be ready... statefulset rolling update complete 3 pods at revision zk-5db4499664... ``` -이것은 파드를 역순으로 한번에 하나씩 종료하고, 새로운 구성으로 재생성한다. 이는 롤링업데이트 동안에 쿼럼을 유지하도록 보장한다. +이것은 파드를 역순으로 한 번에 하나씩 종료하고, 새로운 구성으로 재생성한다. 이는 롤링업데이트 동안에 쿼럼을 유지하도록 보장한다. 이력과 이전 구성을 보기 위해 `kubectl rollout history` 명령을 이용하자. @@ -661,13 +661,13 @@ statefulset.apps/zk rolled back 이것이 기본 값이다. 상태가 유지되는 애플리케이션을 위해 기본 정책을 **절대로** 변경하지 말자. -`zk-0` 파드에서 실행중인 ZooKeeper 서버에서 프로세스 트리를 살펴보기 위해 다음 명령어를 이용하자. +`zk-0` 파드에서 실행 중인 ZooKeeper 서버에서 프로세스 트리를 살펴보기 위해 다음 명령어를 이용하자. ```shell kubectl exec zk-0 -- ps -ef ``` -컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되엇으며 +컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며 ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다. ```shell UID PID PPID C STIME TTY TIME CMD @@ -772,7 +772,7 @@ zk-0 1/1 Running 1 1h 준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케쥴링되고 건강하다. 프로세스가 준비되면 입력을 처리할 수 있다. 활성도는 필수적이나 준비도의 조건으로는 -충분하지 않다. 몇몇의 경우 +충분하지 않다. 몇몇 경우 특별히 초기화와 종료 시에 프로세스는 살아있지만 준비되지 않을 수 있다. @@ -855,7 +855,7 @@ kubernetes-node-2g2d **이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면, 다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.** -이전 섹션은 계획되지 않은 노드 실패에서 살아 남도록 +이전 섹션은 계획되지 않은 노드 실패에서 살아남도록 어떻게 파드를 확산할 것인가에 대해 알아보았다. 그러나 계획된 점검으로 인해 발생하는 일시적인 노드 실패에 대한 계획도 필요하다. @@ -996,7 +996,7 @@ kubectl 을 종료하기 위해 `CTRL-C`를 이용하자. kubectl exec zk-0 zkCli.sh get /hello ``` -`PodDisruptionBudget`이 존중되기 떄문에 서비스는 여전히 가용하다. +`PodDisruptionBudget`이 존중되기 때문에 서비스는 여전히 가용하다. ```shell WatchedEvent state:SyncConnected type:None path:null @@ -1071,7 +1071,7 @@ node "kubernetes-node-i4c4" drained 이번엔 `kubectl drain` 이 성공한다. -`zk-2`가 재스케줄되도록 두번째 노드의 통제를 풀어보자. +`zk-2`가 재스케줄되도록 두 번째 노드의 통제를 풀어보자. ```shell kubectl uncordon kubernetes-node-ixsl @@ -1081,7 +1081,7 @@ kubectl uncordon kubernetes-node-ixsl node "kubernetes-node-ixsl" uncordoned ``` -`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다. +`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다. {{% /capture %}} {{% capture cleanup %}} diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 663e01dc5baba..62b740a044a71 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -21,7 +21,7 @@ card: * Redis 마스터를 시작 * Redis 슬레이브를 시작 * 방명록 프론트엔드를 시작 -* 프론트엔드 서비스를 노출시키고 확인 +* 프론트엔드 서비스를 노출하고 확인 * 정리 하기 {{% /capture %}} @@ -46,7 +46,7 @@ card: {{< codenew file="application/guestbook/redis-master-deployment.yaml" >}} 1. 매니페스트 파일을 다운로드한 디렉토리에서 터미널 창을 시작한다. -1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용시킨다. +1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다. ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml @@ -81,7 +81,7 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다. {{< codenew file="application/guestbook/redis-master-service.yaml" >}} -1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용시킨다. +1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용한다. ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml @@ -118,7 +118,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 {{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}} -1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용시킨다. +1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용한다. ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml @@ -145,7 +145,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 {{< codenew file="application/guestbook/redis-slave-service.yaml" >}} -1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용시킨다. +1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용한다. ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml @@ -166,7 +166,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 redis-slave ClusterIP 10.0.0.223 6379/TCP 6s ``` -## 방명록 프론트엔드를 설정하고 노출시키기 +## 방명록 프론트엔드를 설정하고 노출하기 방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 쓰기 요청을 위한 `redis-master` 서비스와 읽기 요청을 위한 `redis-slave` 서비스에 연결하도록 설정된다. @@ -174,7 +174,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 {{< codenew file="application/guestbook/frontend-deployment.yaml" >}} -1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용시킨다. +1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용한다. ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml diff --git a/content/ko/examples/service/networking/ingress.yaml b/content/ko/examples/service/networking/ingress.yaml new file mode 100644 index 0000000000000..56a0d5138f4e4 --- /dev/null +++ b/content/ko/examples/service/networking/ingress.yaml @@ -0,0 +1,9 @@ +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: test-ingress +spec: + backend: + serviceName: testsvc + servicePort: 80 +