Merge pull request #22362 from pjhwa/fix-22360

Fix issue with 'Linux' and 'Windows' notation in Korean docs

content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -58,8 +58,8 @@ kubectl config use-context
 ## KUBECONFIG 환경 변수
 
 `KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다.
-Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
-Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다.
+리눅스 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
+윈도우는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다.
 `KUBECONFIG` 환경 변수가 없으면,
 `kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다.
 

content/ko/docs/concepts/services-networking/service.md

@@ -1094,7 +1094,7 @@ IP 주소를 정리한다.
 
 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,
 서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는
-iptables (Linux의 패킷 처리 로직)를 필요에 따라
+iptables (리눅스의 패킷 처리 로직)를 필요에 따라
 명백하게 리다이렉션되는 _가상_ IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에
 연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다.
 환경 변수와 서비스 용 DNS는 실제로 서비스의
@@ -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}

content/ko/docs/concepts/workloads/pods/init-containers.md

@@ -62,7 +62,7 @@ weight: 40
   다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다.
 * 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
   공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
-* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다.
+* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 리눅스 네임스페이스를 사용한다.
   결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는
   {{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다.
 * 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱

content/ko/docs/concepts/workloads/pods/pod.md

@@ -29,7 +29,7 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
 쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
 도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다.
 
-파드의 공유 컨텍스트는 Linux 네임 스페이스, 컨트롤 그룹(cgroup) 및
+파드의 공유 컨텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
 도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
 파드의 컨텍스트 내에서 개별 응용 프로그램은
 추가적으로 하위 격리가 적용된다.
@@ -180,7 +180,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
 1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다.
 
-기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). 
+기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제).
 kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다.
 
 ### 파드 강제 삭제

content/ko/docs/reference/glossary/docker.md

@@ -14,5 +14,5 @@ tags:
 
 <!--more-->
 
-Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. 
+Docker는 리눅스 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 리눅스 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. 
 

content/ko/docs/setup/learning-environment/minikube.md

@@ -447,9 +447,9 @@ spec:
 
 | Driver | OS | HostFolder | VM |
 | --- | --- | --- | --- |
-| VirtualBox | Linux | /home | /hosthome |
+| VirtualBox | 리눅스 | /home | /hosthome |
 | VirtualBox | macOS | /Users | /Users |
-| VirtualBox | Windows | C://Users | /c/Users |
+| VirtualBox | 윈도우 | C://Users | /c/Users |
 | VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
 | Xhyve | macOS | /Users | /Users |
 
@@ -505,7 +505,7 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit
 * **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자.
 * **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자.
 * **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자.
-* **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다.
+* **MicroK8s**: 가상 머신을 사용하지 않으려는 리눅스 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다.
 
 ## 커뮤니티
 

content/ko/docs/setup/production-environment/container-runtimes.md

@@ -25,7 +25,7 @@ weight: 10
 ### 적용 가능성
 
 {{< note >}}
-이 문서는 Linux에 CRI를 설치하는 사용자를 위해 작성되었다.
+이 문서는 리눅스에 CRI를 설치하는 사용자를 위해 작성되었다.
 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
 {{< /note >}}
 
@@ -34,7 +34,7 @@ weight: 10
 
 ### Cgroup 드라이버
 
-Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는
+리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는
 root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다.
 Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다.
 컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다.

content/ko/docs/setup/production-environment/tools/kops.md

@@ -9,7 +9,7 @@ weight: 20
 이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다.
 [`kops`](https://github.com/kubernetes/kops)라는 이름의 툴을 이용할 것이다.
 
-kops는 자동화된 프로비저닝 시스템인데, 
+kops는 자동화된 프로비저닝 시스템인데,
 
 * 완전 자동화된 설치
 * DNS를 통해 클러스터들의 신원 확인
@@ -82,7 +82,7 @@ brew update && brew install kops
 ```
 
 {{% /tab %}}
-{{% tab name="Linux" %}}
+{{% tab name="리눅스" %}}
 
 최신 릴리즈를 다운로드 받는 명령어:
 
@@ -127,7 +127,7 @@ brew update && brew install kops
 kops는 클러스터 내부와 외부 모두에서 검색을 위해 DNS을 사용하기에 클라이언트에서 쿠버네티스 API 서버에 연결할
 수 있다.
 
-이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 
+이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써
 사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며,
 IP를 기억할 필요없이 접근할 수 있다.
 
@@ -140,7 +140,7 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone
 `example.com`하위에는 그렇지 않을 수 있다).
 
 `dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자.
-보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 
+보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나
 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다.
 
 그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는,
@@ -175,7 +175,7 @@ S3 버킷 이름으로 정하자.
 
 * `aws s3 mb s3://clusters.dev.example.com`를 이용해 S3 버킷을 생성한다.
 
-* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다. 
+* `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 하면, kops는 이 위치를 기본값으로 인식할 것이다.
    이 부분을 bash profile등에 넣어두는것을 권장한다.
 
 
@@ -185,7 +185,7 @@ S3 버킷 이름으로 정하자.
 
 `kops create cluster --zones=us-east-1c useast1.dev.example.com`
 
-kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_ 
+kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 _설정_
 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 `kops update cluster` 으로
 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다.
 

content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -268,26 +268,26 @@ contexts:
 이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다.
 예:
 
-### Linux
+### 리눅스
 ```shell
 export  KUBECONFIG_SAVED=$KUBECONFIG
 ```
-### Windows PowerShell
+### 윈도우 PowerShell
 ```shell
 $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
 ```
 `KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
-Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
+리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다.
 `KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
 익숙해지길 바란다.
 
 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.
 
-### Linux
+### 리눅스
 ```shell
 export  KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
 ```
-### Windows PowerShell
+### 윈도우 PowerShell
 ```shell
 $Env:KUBECONFIG=("config-demo;config-demo-2")
 ```
@@ -346,11 +346,11 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
 환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자.
 예:
 
-### Linux
+### 리눅스
 ```shell
 export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
 ```
-### Windows Powershell
+### 윈도우 Powershell
 ```shell
  $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
 ```
@@ -366,12 +366,12 @@ kubectl config view
 
 `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br>
 
-### Linux
+### 리눅스
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```
 
-### Windows PowerShell
+### 윈도우 PowerShell
 ```shell
  $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 ```

content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md

@@ -1,5 +1,5 @@
 ---
-title: Windows 노드 추가
+title: 윈도우 노드 추가
 min-kubernetes-server-version: 1.17
 content_type: tutorial
 weight: 30
@@ -9,16 +9,16 @@ weight: 30
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-쿠버네티스를 사용하여 리눅스와 Windows 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 Windows에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 Windows 노드를 클러스터에 등록하는 방법을 보여준다.
+쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다.
 
 
 
 
 ## {{% heading "prerequisites" %}}
  {{< version-check >}}
 
-* Windows 컨테이너를 호스팅하는 Windows 노드를 구성하려면
-[Windows Server 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
+* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면
+[윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
 VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다.
 
 * 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다.
@@ -29,15 +29,15 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
 ## {{% heading "objectives" %}}
 
 
-* 클러스터에 Windows 노드 등록
-* 리눅스 및 Windows의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
+* 클러스터에 윈도우 노드 등록
+* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
 
 
 
 
 <!-- lessoncontent -->
 
-## 시작하기: 클러스터에 Windows 노드 추가
+## 시작하기: 클러스터에 윈도우 노드 추가
 
 ### 네트워킹 구성
 
@@ -75,7 +75,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
         }
     ```
 
-    {{< note >}}리눅스의 플란넬이 Windows의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
+    {{< note >}}리눅스의 플란넬이 윈도우의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
     참고한다.{{< /note >}}
 
     {{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}}
@@ -102,9 +102,9 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
     kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
     ```
 
-1. Windows 플란넬 및 kube-proxy 데몬셋 추가
+1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가
 
-    이제 Windows 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
+    이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
     kube-proxy 버전을 얻으려면, 이미지의 태그를
     대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만,
     사용자의 배포에 맞게 버전을 조정해야 한다.
@@ -118,7 +118,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
     {{< /note >}}
 
     {{< note >}}
-Windows 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
+윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
 
 ```powershell
 wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
@@ -134,14 +134,14 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
 
 
 
-### Windows 워커 노드 조인(joining)
+### 윈도우 워커 노드 조인(joining)
 {{< note >}}
 `Containers` 기능을 설치하고 도커를 설치해야 한다.
-[Windows Server에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
+[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
 {{< /note >}}
 
 {{< note >}}
-Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의
+윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의
 높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
 {{< /note >}}
 
@@ -160,7 +160,7 @@ Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의
 
 
 #### 설치 확인
-이제 다음을 실행하여 클러스터에서 Windows 노드를 볼 수 있다.
+이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.
 
 ```bash
 kubectl get nodes -o wide
@@ -180,6 +180,6 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드
 ## {{% heading "whatsnext" %}}
 
 
-- [Windows kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
+- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)