whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Seventh Korean l10n work for release 1.18

Browse Source 
- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240)
- Fix issue of broken links to translated docs (#22105)
- Fix issue of document link in some ko documents (#22379)
- Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776)
- Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362)
- Fix issue of broken links to translated docs #2 (#22270)
- Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261)
- Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263)
- Fix incorrect notation of 'directory' into Korean (#22155)
- Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232)
- Update outdated files in dev-1.18-ko.7 (#22128)
- Modify spacing term ReplicaSet in Korean (#22148)
- Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849)
- Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: woopyoung <ywp041@gmail.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>
This commit is contained in:
June Yi
2020-07-10 12:38:02 +09:00
parent 2a4923f49a
commit f604a4b60a
148 changed files with 2604 additions and 1350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+30 -26
View File
@@ -2,27 +2,28 @@
title: HostAliases로 파드의 /etc/hosts 항목 추가하기
content_type: concept
weight: 60
min-kubernetes-server-version: 1.7
---
{{< toc >}}
<!-- overview -->
파드의 /etc/hosts 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. 1.7 버전에서는, 사용자들이 PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다.
HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 Kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다.
파드의 `/etc/hosts` 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다.
HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다.
<!-- body -->
## 기본 호스트 파일 내용
파드 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 >}}
content/ko/docs/concepts/services-networking/connect-applications-service.md
+2 -4
View File
@@ -50,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
만약 궁금하다면 [우리가 이것을 달성하는 방법](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)을 자세히 읽어본다.
만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다.
## 서비스 생성하기
@@ -198,7 +198,7 @@ kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
```
이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP
에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/docs/tasks/administer-cluster/coredns/#installing-coredns)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다.
에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/ko/docs/tasks/administer-cluster/coredns/#coredns-설치)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다.
```shell
kubectl run curl --image=radial/busyboxplus:curl -i --tty
@@ -422,5 +422,3 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
* [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
content/ko/docs/concepts/services-networking/endpoint-slices.md
+1 -2
View File
@@ -41,7 +41,7 @@ term_id="selector" >}} 가 지정되면 EndpointSlice
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
EndpointSlice 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
리소스 샘플이 있다.
@@ -180,4 +180,3 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
content/ko/docs/concepts/services-networking/ingress.md
+3 -4
View File
@@ -18,7 +18,7 @@ weight: 40
* 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
## 인그레스란?
@@ -79,8 +79,8 @@ spec:
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
인그레스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
@@ -547,4 +547,3 @@ Events:
* [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
content/ko/docs/concepts/services-networking/service.md
+8 -8
View File
@@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
새 인스턴스를 생성할 수 있다.
서비스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@@ -168,7 +168,7 @@ subsets:
```
엔드포인트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
{{< note >}}
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
@@ -272,7 +272,7 @@ kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드
다르다. 해당 시나리오에서는, kube-proxy는 첫 번째
파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다.
파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 사용하여
파드 [준비성 프로브(readiness probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 사용하여
백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는
정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해
실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다.
@@ -418,7 +418,7 @@ DNS 만 사용하여 서비스의 클러스터 IP를 검색하는 경우, 이
### DNS
[애드-온](/docs/concepts/cluster-administration/addons/)을 사용하여 쿠버네티스
[애드-온](/ko/docs/concepts/cluster-administration/addons/)을 사용하여 쿠버네티스
클러스터의 DNS 서비스를 설정할 수(대개는 필수적임) 있다.
CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위해 쿠버네티스 API를 감시하고
@@ -1094,7 +1094,7 @@ IP 주소를 정리한다.
실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,
서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는
iptables (Linux의 패킷 처리 로직)를 필요에 따라
iptables (리눅스의 패킷 처리 로직)를 필요에 따라
명백하게 리다이렉션되는 _가상_ IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에
연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다.
환경 변수와 서비스 용 DNS는 실제로 서비스의
@@ -1176,7 +1176,7 @@ HTTP / HTTPS 서비스를 노출할 수도 있다.
### PROXY 프로토콜
클라우드 공급자가 지원하는 경우에 (예: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
클라우드 공급자가 지원하는 경우에 (예: [AWS](/ko/docs/concepts/cluster-administration/cloud-providers/#aws)),
LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에
로드 밸런서를 구성할 수 있으며, 이때 접두사가
[PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다.
@@ -1213,10 +1213,10 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
클라우드 공급자의 로드 밸런서 구현이 프로토콜로서 SCTP를 지원하는 경우에만 LoadBalancer `유형`과 SCTP `프로토콜`을 사용하여 서비스를 생성할 수 있다. 그렇지 않으면, 서비스 생성 요청이 거부된다. 현재 클라우드 로드 밸런서 공급자 세트 (Azure, AWS, CloudStack, GCE, OpenStack)는 모두 SCTP에 대한 지원이 없다.
{{< /warning >}}
##### Windows {#caveat-sctp-windows-os}
##### 윈도우 {#caveat-sctp-windows-os}
{{< warning >}}
SCTP는 Windows 기반 노드를 지원하지 않는다.
SCTP는 윈도우 기반 노드를 지원하지 않는다.
{{< /warning >}}
##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace}