diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 50291bd72d234..09143afa7d73d 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -57,7 +57,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 각 클러스터에 대하여 - Google 컴퓨트 엔진 또는 Google 쿠버네티스 엔진에서 자동적으로 구성됨 - 모든 파드는 해당 프로젝트의 프라이빗 레지스트리를 읽을 수 있음 - - AWS EC2 컨테이너 레지스트리(ECR) 사용 + - AWS Elastic Container Registry(ECR) 사용 - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함 - ECR 로그인 자격 증명은 자동으로 갱신됨 - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 @@ -67,7 +67,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 - - 미리 풀링(pre-pulling)된 이미지 + - 미리 내려받은(pre-pulled) 이미지 - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 - 파드에 ImagePullSecrets을 명시 @@ -89,10 +89,9 @@ Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 GCR을 인스턴스의 서비스 계정은 `https://www.googleapis.com/auth/devstorage.read_only`라서, 프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다. -### AWS EC2 컨테이너 레지스트리 사용 +### Amazon Elastic Container Registry 사용 -쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [AWS EC2 컨테이너 -레지스트리](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. +쿠버네티스는 노드가 AWS EC2 인스턴스일 때, [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/)를 자연스럽게 지원한다. 간단히 이미지의 전체 이름(예: `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)을 파드 정의에 사용하면 된다. @@ -240,7 +239,7 @@ kubectl describe pods/private-image-test-1 | grep "Failed" 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. -### 미리 풀링(pre-pulling)된 이미지 +### 미리 내려받은 이미지 {{< note >}} Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다. @@ -257,11 +256,11 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 로컬 이미지가 사용된다(우선적으로 또는 배타적으로). 레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면, -클러스터의 모든 노드가 동일한 미리 풀 된 이미지를 가지고 있는지 확인해야 한다. +클러스터의 모든 노드가 동일한 미리 내려받은 이미지를 가지고 있는지 확인해야 한다. 이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다. -모든 파드는 미리 풀 된 이미지에 대해 읽기 접근 권한을 가질 것이다. +모든 파드는 미리 내려받은 이미지에 대해 읽기 접근 권한을 가질 것이다. ### 파드에 ImagePullSecrets 명시 diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 1555ff06e462b..3c9aaa09ecc2f 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -19,7 +19,7 @@ card: 파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함. -[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다. +[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다. 쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다. diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index f58d6f8b4faa7..a51e56dfd626c 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -139,7 +139,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 위와 같은 기능 제공을 할 수 있다. -사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. +사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. 파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다: diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md index 61a857e58e68a..cd850a828bd77 100644 --- a/content/ko/docs/reference/glossary/device-plugin.md +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -4,7 +4,7 @@ id: device-plugin date: 2019-02-02 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > - 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + 쿠버네티스에서 동작하는 컨테이너로, 공급 업체 고유의 리소스에 대한 액세스를 제공한다. aka: tags: - fundamental @@ -14,4 +14,4 @@ tags: -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 kubelet에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 데몬 셋으로도 디플로이 가능하다. +[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로도 디플로이 가능하다. diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md index 5f8a4fc612af6..ea7eb79d580be 100755 --- a/content/ko/docs/reference/glossary/kube-proxy.md +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -2,21 +2,19 @@ title: kube-proxy id: kube-proxy date: 2018-04-12 -full_link: /docs/reference/generated/kube-proxy +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ short_description: > `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. aka: tags: - fundamental -- core-object +- networking --- - `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. - -이는 호스트의 네트워크 규칙을 관리하고 접속 포워딩을 수행하여 -쿠버네티스 서비스 추상화를 가능케 한다. + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 {{< glossary_tooltip text="서비스" term_id="service">}} 개념의 구현부이다. -`kube-proxy`는 요청에 대한 포워딩을 책임진다. `kube-proxy`는 TCP 및 UDP 스트림 포워딩을 허용하거나 TCP 및 UDP 포워딩을 백 엔드 기능 집합에 걸쳐 라운드 로빈을 제공한다. +kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. +kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.