Merge pull request #24119 from kubernetes/dev-1.19-ko.2

Second Korean l10n work for release-1.19
2020-09-24 23:13:11 -07:00
parent ab8fb532fa 9cb997ab15
commit 28980202c1
64 changed files with 2203 additions and 527 deletions
@@ -5,12 +5,12 @@ content_type: concept

 <!-- overview -->

+{{% thirdparty-content %}}
+
 애드온은 쿠버네티스의 기능을 확장한다.

 이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다.

-각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다.
-
 <!-- body -->

 ## 네트워킹과 네트워크 폴리시
@@ -1,362 +0,0 @@
---
-title: 클라우드 제공자
-content_type: concept
-weight: 30
---
-
-<!-- overview -->
-이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에
-대해 설명한다. 다른 많은 타사 클라우드 제공자 프로젝트가 있지만, 이 목록은 쿠버네티스 자체에 의존하거나, 포함되어있는 프로젝트에 한정한다.
-
-<!-- body -->
-### kubeadm
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다.
-kubeadm에는 클라우드 제공자에 대한 구성 정보를 지정하는 구성 옵션이 있다. 예를 들어
-kubeadm을 사용하여 일반적인 인-트리(in-tree) 클라우드 제공자를 아래와 같이 구성할 수 있다.
-
-```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: InitConfiguration
-nodeRegistration:
-  kubeletExtraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
---
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
-apiServer:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-controllerManager:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-```
-
-인-트리 클라우드 제공자는 일반적으로
-[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
-[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
-및 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다.
-각 제공자에 대해 `--cloud-config` 에 지정된 파일의 내용도 아래에 설명되어 있다.
-
-모든 외부 클라우드 제공자의 경우, 아래 제공자에 대한 제목 아래에 있는 개별 리포지터리의 지침을 따르거나,
-[모든 리포지터리 목록](https://github.com/kubernetes?q=cloud-provider-&type=&language=)을 볼 수 있다
-
-## AWS
-이 섹션에서는 Amazon Web Services에서 쿠버네티스를 실행할 때 사용할 수 있는
-모든 구성에 대해 설명한다.
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)이다.
-
-### 노드 이름
-
-AWS 클라우드 제공자는 AWS 인스턴스의 프라이빗 DNS 이름을 쿠버네티스 노드 오브젝트의 이름으로 사용한다.
-
-### 로드 밸런서
-아래와 같이 어노테이션을 구성하여 AWS의 특정 기능을 사용하도록
-[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 설정할 수 있다.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: example
-  namespace: kube-system
-  labels:
-    run: example
-  annotations:
-     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #이 값을 교체한다
-     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
-spec:
-  type: LoadBalancer
-  ports:
-  - port: 443
-    targetPort: 5556
-    protocol: TCP
-  selector:
-    app: example
-```
-_어노테이션_ 을 사용하여 AWS의 로드 밸런서 서비스에 다른 설정을 적용할 수 있다. 다음은 AWS ELB에서 지원하는 어노테이션에 대해 설명한다.
-
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: 액세스 로그 방출 간격을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: 서비스에서 액세스 로그를 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: 액세스 로그 s3 버킷 이름을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: 액세스 로그 s3 버킷 접두사를 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: 서비스에서 쉼표로 구분된 키-값 쌍의 목록을 지정하여 ELB에 추가 태그로 기록된다. 예를 들면 다음과 같다. `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`
-* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: 서비스에서 리스너 뒤의 백엔드(파드)가 언급한 프로토콜을 지정하는 데 사용된다. 만약 `http` (기본값) 또는 `https` 인 경우, 연결을 종료하고 헤더를 파싱하는 HTTPS 리스너가 생성된다. `ssl` 이나 `tcp` 로 설정된 경우, "원시(raw)" SSL 리스너가 사용된다. `http` 로 설정하고 `aws-load-balancer-ssl-cert` 를 사용하지 않았다면 HTTP 리스너가 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: 서비스에서 보안 리스너를 요청하는 데 사용된다. 값은 유효한 인증서 ARN이다. 자세한 내용은, [ELB 리스너 구성](https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/classic/elb-listener-config.html)을 참고한다. CertARN은 IAM 또는 CM 인증서 ARN이다(예: `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`).
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 서비스에서 연결 드레이닝(draining)을 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 서비스에서 연결 드레이닝 타임아웃 값을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: 서비스에서 유휴 연결 타임아웃 값을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: 서비스에서 교차 영역의 로드 밸런싱을 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. 여기에 정의된 보안 그룹은 서비스 간에 공유해서는 안된다.
-* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 서비스에서 생성된 ELB에 추가할 추가적인 보안 그룹을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-internal`: 서비스에서 내부 ELB 사용 희망을 표시하기 위해 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: 서비스에서 ELB에서 프록시 프로토콜을 활성화하는 데 사용된다. 현재는 모든 ELB 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPS 리스너를 사용할 쉼표로 구분된 포트의 목록을 지정하기 위해 서비스에서 사용된다. 기본값은 `*`(모두)이다.
-
-AWS 어노테이션에 대한 정보 출처는 [aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)의 코멘트이다.
-
-## Azure
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)이다.
-
-### 노드 이름
-
-Azure 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름(hostname)을 사용한다.
-참고로 쿠버네티스 노드 이름은 Azure VM 이름과 일치해야 한다.
-
-## GCE
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)이다.
-
-### 노드 이름
-
-GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
-참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함).
-
-## HUAWEI CLOUD
-
-외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다.
-
-## OpenStack
-이 섹션에서는 쿠버네티스와 함께 OpenStack을 사용할 때 사용할 수 있는
-모든 구성에 대해 설명한다.
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)이다.
-
-### 노드 이름
-
-OpenStack 클라우드 제공자는 (OpenStack 메타데이터에서 결정한) 인스턴스 이름을 쿠버네티스 노드 오브젝트의 이름으로 사용한다.
-참고로 kubelet이 노드 오브젝트를 성공적으로 등록하려면 인스턴스 이름이 유효한 쿠버네티스 노드 이름이어야 한다.
-
-### 서비스
-
-쿠버네티스에 대한
-OpenStack 클라우드 제공자 구현은 사용 가능한 경우 기본 클라우드에서
-이러한 OpenStack 서비스 사용을 지원한다.
-
-| 서비스                    | API 버전         | 필수      |
-|--------------------------|----------------|----------|
-| 블록 스토리지 (Cinder)      | V1†, V2, V3    | 아니오     |
-| 컴퓨트 (Nova)              | V2             | 아니오    |
-| 아이덴티티(Identity) (Keystone) | V2‡,  V3       | 예        |
-| 로드 밸런싱 (Neutron)       | V1§, V2        | 아니오     |
-| 로드 밸런싱 (Octavia)       | V2             | 아니오     |
-
-† 블록 스토리지 V1 API 지원은 사용 중단(deprecated)되며, 쿠버네티스 1.9에서 블록 스토리지
-V3 API 지원이 추가되었다.
-
-‡ 아이덴티티 V2 API 지원은 사용 중단되며, 향후 릴리스에서는 제공자에서
-제거될 예정이다. "Queens" 릴리스부터 OpenStack은 더 이상 아이덴티티 V2 API를
-공개하지 않는다.
-
-§ 로드 밸런싱 V1 API 지원이 쿠버네티스 1.9에서 제거되었다.
-
-서비스 디스커버리는 제공자 구성에서 제공된 `auth-url` 을 사용하여
-OpenStack 아이덴티티(Keystone)에서 관리하는 서비스 카탈로그를
-나열하여 수행된다. Keystone 이외의 OpenStack 서비스를 사용할 수 없고
-영향을 받는 기능에 대한 지원을 거부할 경우 제공자는 기능이
-점진적으로 떨어진다. 기본 클라우드에서 Neutron이 게시한 확장 목록을 기반으로
-특정 기능을 활성화하거나 비활성화할 수도 있다.
-
-### cloud.conf
-쿠버네티스는 cloud.conf 파일을 통해 OpenStack과 상호 작용하는 방법을 알고 있다. 쿠버네티스에
-OpenStack 인증 엔드포인트의 자격 증명과 위치를 제공하는 파일이다.
-다음의 세부 정보를 지정하여 cloud.conf 파일을 만들 수 있다.
-
-#### 일반적인 구성
-이것은 가장 자주 설정해야 하는 값에 대한 일반적인 구성의
-예시이다. OpenStack 클라우드의 Keystone
-엔드포인트에서, 제공자를 가리키고 이를 인증하는 방법에 대한 세부 사항을 제공하고,
-로드 밸런서를 구성한다.
-
-```yaml
-[Global]
-username=user
-password=pass
-auth-url=https://<keystone_ip>/identity/v3
-tenant-id=c869168a828847f39f7f06edd7305637
-domain-id=2a73b8f597c04551a0fdc8e95544be8a
-
-[LoadBalancer]
-subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
-```
-
-##### 글로벌
-OpenStack 제공자에 대한 다음의 구성 옵션은 글로벌
-구성과 관련이 있으며 `cloud.conf` 파일의 `[Global]` 섹션에 있어야
-한다.
-
-* `auth-url` (필수): 인증에 사용되는 Keystone API의 URL이다.
-  OpenStack 제어판의 액세스 및 보안 > API 액세스 >
-  자격 증명에서 찾을 수 있다.
-* `username` (필수): Keystone에 설정된 유효한 사용자의 username을 나타낸다.
-* `password` (필수): Keystone에 설정된 유효한 사용자의 password를 나타낸다.
-* `tenant-id` (필수): 리소스를 생성하려는 프로젝트의 id를 지정하는 데
-  사용된다.
-* `tenant-name` (선택): 리소스를 생성하려는 프로젝트의 이름을
-  지정하는 데 사용된다.
-* `trust-id` (선택): 권한 부여에 사용할 트러스트(trust)의 식별자를 지정하는 데
-  사용된다. 트러스트는 한 사용자(트러스터(trustor))의 권한을 다른 사용자(트러스티(trustee))에게 역할을
-  위임하고, 선택적으로 트러스티가 트러스터를 가장하도록
-  허용한다. 사용 가능한 트러스트는
-  Keystone API의 `/v3/OS-TRUST/trusts` 엔드포인트 아래에 있다.
-* `domain-id` (선택): 사용자가 속한 도메인의 id를 지정하는 데
-  사용된다.
-* `domain-name` (선택): 사용자가 속한 도메인의 이름을 지정하는 데
-  사용된다.
-* `region` (선택): 멀티-리전(multi-region) OpenStack 클라우드에서
-  실행할 때 사용할 리전의 식별자를 지정하는 데 사용된다. 리전은 OpenStack 디플로이먼트의
-  일반 디비전(division)이다. 리전에 엄격한 지리적 의미는 없지만,
-  디플로이먼트 시 `us-east` 와 같은
-  리전의 식별자에 지리적 이름을 사용할 수 있다. 사용 가능한 지역은
-  Keystone API의 `/v3/regions` 엔드포인트 아래에 있다.
-* `ca-file` (선택): 사용자 지정 CA 파일의 경로를 지정하는 데 사용된다.
-
-
-테넌트를 프로젝트로 변경하는 Keystone V3을 사용하면 `tenant-id` 값이
-API의 프로젝트 구성에 자동으로 매핑된다.
-
-#####  로드 밸런서
-OpenStack 제공자에 대한 다음의 구성 옵션은 로드 밸런서와 관련이 있으며
-`cloud.conf` 파일의 `[LoadBalancer]` 섹션에 있어야
-한다.
-
-* `lb-version` (선택): 자동 버전 감지를 대체하는 데 사용된다. 유효한
-  값은 `v1` 또는 `v2` 이다. 값이 제공되지 않는 경우 자동 감지는
-  기본 OpenStack 클라우드에 의해 제공되는 가장 최신의 지원되는 버전을
-  선택한다.
-* `use-octavia` (선택): Neutron-LBaaS를 사용하는 대신 LoadBalancer 유형의
-  서비스 구현에 Octavia를 사용할지 여부를 결정한다. 기본값: true
-  주의: Openstack CCM은 v1.17.0 이후로 기본 로드 밸런서 구현으로 Octavia를 사용한다.
-* `subnet-id` (선택): 로드 밸런서를 생성하려는 서브넷의 id를
-  지정하는 데 사용된다. Network > Networks 에서 찾을 수 있다. 해당
-  네트워크를 클릭하여 서브넷을 가져온다.
-* `floating-network-id` (선택): 지정된 경우, 로드 밸런서에 대한 유동 IP를
-  생성한다.
-* `lb-method` (선택): 로드 밸런서 풀(pool)의 멤버 간에 부하가
-  분산되는 알고리즘을 지정하는 데 사용된다. 값은
-  `ROUND_ROBIN`, `LEAST_CONNECTIONS` 또는 `SOURCE_IP` 가 될 수 있다. 지정되지
-  않은 경우 기본 동작은 `ROUND_ROBIN` 이다.
-* `lb-provider` (선택): 로드 밸런서의 제공자를 지정하는 데 사용된다.
-  지정하지 않으면, neutron에 구성된 기본 제공자 서비스가
-  사용된다.
-* `create-monitor` (선택): Neutron 로드 밸런서에 대한 헬스 모니터를
-  생성할지의 여부를 나타낸다. 유효한 값은 `true` 및 `false` 이다.
-  기본값은 `false` 이다. `true` 가 지정되면 `monitor-delay`,
-  `monitor-timeout` 및 `monitor-max-retries` 도 설정해야 한다.
-* `monitor-delay` (선택): 로드 밸런서의 멤버에게 프로브(probe)를
-  보내는 간격의 시간이다. 유효한 시간 단위를 지정해야 한다. 유효한 시간 단위는 "ns", "us"(또는 "µs"), "ms", "s", "m", "h"이다.
-* `monitor-timeout` (선택): 모니터가 타임아웃 되기 전에 핑(ping) 응답을
-  기다리는 최대 시간이다. 값은 지연 값보다 작아야
-  한다. 유효한 시간 단위를 지정해야 한다. 유효한 시간 단위는 "ns", "us"(또는 "µs"), "ms", "s", "m", "h"이다.
-* `monitor-max-retries` (선택): 로드 밸런서 멤버의 상태를 INACTIVE로
-  변경하기 전에 허용되는 핑 오류 수이다. 1에서 10 사이의
-  숫자여야 한다.
-* `manage-security-groups` (선택): 로드 밸런서가 보안 그룹 규칙을
-  자동으로 관리해야 하는지의 여부를 결정한다. 유효한 값은
-  `true` 및 `false` 이다. 기본값은 `false` 이다. `true` 가 지정되면
-  `node-security-group` 도 제공해야 한다.
-* `node-security-group` (선택): 관리할 보안 그룹의 ID이다.
-
-##### 블록 스토리지
-OpenStack 제공자에 대한 다음의 구성 옵션은 블록 스토리지와 관련이 있으며
-`cloud.conf` 파일의 `[BlockStorage]` 섹션에 있어야 한다.
-
-* `bs-version` (선택): 자동 버전 감지를 대체하는 데 사용된다. 유효한
-  값은 `v1`, `v2`, `v3` 및 `auto` 이다. `auto` 가 지정되면 자동
-  감지는 기본 OpenStack 클라우드에 의해 노출되는 가장 최신의 지원되는
-  버전을 선택한다. 제공되지 않은 경우 기본값은 `auto` 이다.
-* `trust-device-path` (선택): 대부분의 시나리오에서 Cinder가 제공한
-  블록 장치 이름(예: `/dev/vda`)을 신뢰할 수 없다. 이 부울은
-  이 동작을 토글(toggle)한다. 이를 `true` 로 설정하면 Cinder에서 제공한
-  블록 장치 이름을 신뢰하게 된다. 기본값인 `false` 는 일련 번호와
-  `/dev/disk/by-id` 를 매핑하여 장치 경로를 검색하게 하며
-  권장하는 방법이다.
-* `ignore-volume-az` (선택): Cinder 볼륨을 연결할 때 가용 영역(availability zone)
-  사용에 영향을 주기 위해 사용된다. Nova와 Cinder의 가용성
-  영역이 서로 다른 경우, 이 값을 `true` 로 설정해야 한다. 이는 가장 일반적인 상황으로 Nova 가용 영역은
-  많지만 Cinder는 하나의 가용 영역만 있는 경우이다.
-  이전 릴리스에서 사용된 동작을 유지하기 위해 기본값은 `false`
-  이지만, 나중에 변경될 수 있다.
-* `node-volume-attach-limit` (선택): 노드에 연결할 수 있는
-  최대 볼륨 수이다. 기본값은 cinder의 경우 256이다.
-
-포트가 아닌 경로를 사용하여 엔드포인트를 구별하는 OpenStack
-디플로이먼트에서 1.8 이하의 쿠버네티스 버전을 배포하는 경우
-명시적으로 `bs-version` 파라미터를 설정해야 한다. 경로 기반의 엔드포인트는
-`http://foo.bar/volume` 형식이며 포트 기반의 엔드포인트는
-`http://foo.bar:xxx` 형식이다.
-
-경로 기반의 엔드포인트를 사용하고 쿠버네티스가 이전 자동 감지 로직을 사용하는 환경에서는
-볼륨 분리 시도 시 `BS API version autodetection failed.` 오류가
-리턴된다. 이 문제를 해결하려면 클라우드 제공자 구성에
-다음을 추가하여 Cinder API 버전 2를 강제로
-사용할 수 있다.
-
-```yaml
-[BlockStorage]
-bs-version=v2
-```
-
-##### 메타데이터
-OpenStack 제공자에 대한 다음의 구성 옵션은 메타데이터와 관련이 있으며
-`cloud.conf` 파일의 `[Metadata]` 섹션에 있어야 한다.
-
-* `search-order` (선택): 이 구성 키는 실행되는 인스턴스와
-  관련된 메타데이터를 제공자가 검색하는 방식에 영향을 준다. 기본값인
-  `configDrive,metadataService` 를 사용할 수 있는 경우에 제공자가
-  먼저 구성 드라이브에서 인스턴스와 관련된 메타데이터를
-  검색한 다음 메타데이터 서비스를 검색하게 한다. 대체할 수 있는 값은 다음과 같다.
-  * `configDrive` - 구성 드라이브에서 인스턴스 메타데이터만
-    검색한다.
-  * `metadataService` - 메타데이터 서비스에서 인스턴스 메타데이터만
-    검색한다.
-  * `metadataService,configDrive` - 사용할 수 있는 경우 먼저 메타데이터
-    서비스에서 인스턴스 메타데이터를 검색한 다음, 구성 드라이브를 검색한다.
-
-  구성 드라이브의 메타데이터는 시간이 지남에 따라
-  오래될 수 있지만, 메타데이터 서비스는 항상 최신 뷰를 제공하므로
-  이러한 설정은 바람직하다. 모든 OpenStack 클라우드가
-  구성 드라이브와 메타데이터 서비스를 모두 제공하는 것은 아니며 하나 또는 다른 하나만
-  사용할 수 있으므로 기본값은 둘 다를 확인하는 것이다.
-
-##### 라우트
-
-OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet]
-쿠버네티스 네트워크 플러그인과 관련이 있으며 `cloud.conf` 파일의 `[Route]` 섹션에
-있어야 한다.
-
-* `router-id` (선택): 기본 클라우드의 Neutron 디플로이먼트가
-  `extraroutes` 확장을 지원하는 경우 경로를 추가할 라우터를 지정하는 데 `router-id`
-  를 사용한다. 선택한 라우터는 클러스터 노드를 포함하는 프라이빗 네트워크에
-  걸쳐 있어야 한다(일반적으로 하나의 노드 네트워크만 있으며, 이 값은
-  노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서
-  [kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을
-  사용하는 데 필요하다.
-
-[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet
-
-## vSphere
-
-{{< tabs name="vSphere cloud provider" >}}
-{{% tab name="vSphere 6.7U3 이상" %}}
-vSphere 6.7U3 이상의 모든 vSphere 디플로이먼트의 경우, [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)와 함께 [외부 vSphere 클라우드 제공자](https://github.com/kubernetes/cloud-provider-vsphere)를 권장한다. 퀵스타트 가이드는 [CSI와 CPI를 사용하여 vSphere에 쿠버네티스 클러스터 배포하기](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)를 참고한다.
-{{% /tab %}}
-{{% tab name="vSphere 6.7U3 미만" %}}
-vSphere 6.7U3 미만을 사용할 경우, 인-트리 vSphere 클라우드 제공자를 권장한다. 퀵스타트 가이드는 [kubeadm을 사용하여 vSphere에 쿠버네티스 클러스터 실행하기](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)를 참고한다.
-{{% /tab %}}
-{{< /tabs >}}
-
-vSphere 클라우드 제공자에 대한 자세한 문서를 보려면, [vSphere 클라우드 제공자 문서 사이트](https://cloud-provider-vsphere.sigs.k8s.io)를 방문한다.
@@ -77,6 +77,8 @@ VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모
 이 목록은 알파벳 순으로 정렬되어 있으며, 정렬된 순서가
 우선 상태를 의미하는 것은 아니다.

+{{% thirdparty-content %}}
+
 ### ACI

 [Cisco 애플리케이션 센트릭 인프라스트럭처(Application Centric Infrastructure)](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html)는 컨테이너, 가상 머신 및 베어메탈 서버를 지원하는 통합 오버레이 및 언더레이 SDN 솔루션을 제공한다. [ACI](https://www.github.com/noironetworks/aci-containers)는 ACI를 위한 컨테이너 네트워킹 통합을 제공한다. 통합의 개요는 [여기](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)에서 제공된다.
@@ -312,4 +314,3 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
 네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
 [네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에
 자세히 설명되어 있다.
-
@@ -214,9 +214,11 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).

+## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
+
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}

-쿠버네티스 베타 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과
+쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
 사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
 데이터 변경을 방지하면 다음과 같은 이점이 있다.
@@ -224,9 +226,10 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 - 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
 - immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴

-이 기능을 사용하려면 `ImmutableEphemeralVolumes`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
-시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
+이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
+게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
+의해 제어된다. `immutable` 필드를 `true` 로 설정하여
+변경할 수 없는 컨피그맵을 생성할 수 있다. 다음은 예시이다.
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -247,7 +250,7 @@ immutable: true
 ## {{% heading "whatsnext" %}}


-* [시크릿](/docs/concepts/configuration/secret/)에 대해 읽어본다.
+* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 읽어본다.
 * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다.
 * 코드를 구성에서 분리하려는 동기를 이해하려면
  [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.
@@ -101,4 +101,4 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며

 - `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다.

- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
+- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
@@ -715,37 +715,6 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신
 받지 않는다.
 {{< /note >}}

-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
-쿠버네티스 베타 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은
-개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
-클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
-다음과 같은 이점이 있다.
-
- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
-크게 줄임으로써 클러스터의 성능을 향상시킴
-
-이 기능을 사용하려면, `ImmutableEphemeralVolumes`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
-시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  ...
-data:
-  ...
-immutable: true
-```
-
-{{< note >}}
-시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
-`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
-기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
-권장한다.
-{{< /note >}}
-
 ### 시크릿을 환경 변수로 사용하기

 파드에서 {{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}에
@@ -806,6 +775,40 @@ echo $SECRET_PASSWORD
 1f2d1e2e67df
 ```

+## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
+개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
+클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
+다음과 같은 이점이 있다.
+
+- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
+- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
+크게 줄임으로써 클러스터의 성능을 향상시킴
+
+이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
+게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
+의해 제어된다. `immutable` 필드를 `true` 로 설정하여
+변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
+기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
+권장한다.
+{{< /note >}}
+
 ### imagePullSecrets 사용하기

 `imagePullSecrets` 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다.
@@ -28,7 +28,7 @@ no_list: true

 설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를
 변경할 수 없다. 컨테이너화된 애플리케이션이 있고
-변경하려는 경우, 변경 사항이 포함된 새 컨테이너를 빌드한
+변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한
 다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다.

 ## 컨테이너 런타임
@@ -7,7 +7,7 @@ weight: 10
 <!-- overview -->

 애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
-추가 API는 [서비스-카탈로그](/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
+추가 API는 [서비스-카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.

 애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다.

@@ -31,6 +31,6 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경
 ## {{% heading "whatsnext" %}}

 * 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
-* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
+* 다음에, [확장 API 서버를 구성해서](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
 * 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.
 * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다.
@@ -96,7 +96,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
 * 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다.

 {{< note >}}
-민감한 데이터에는 [시크릿](/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다.
+민감한 데이터에는 [시크릿](/ko/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다.
 {{< /note >}}

 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.
@@ -136,7 +136,7 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명

 1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은
   API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
-1. 또한, [자신의 확장 API 서버 구현](/docs/tasks/extend-kubernetes/setup-extension-api-server/)과
+1. 또한, [자신의 확장 API 서버 구현](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/)과
   [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를
   사용해서 클라이언트를 원활하게 만들 수 있다.

@@ -77,12 +77,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지
 방법이 있다.

-1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면
-   필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
-1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면
-   `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의
-   다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록
-   kube-scheduler를 구성할 수도 있다.
+1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
+1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.


 ## {{% heading "whatsnext" %}}
@@ -1,7 +1,7 @@
 ---
 title: 스케줄러 성능 튜닝
 content_type: concept
-weight: 70
+weight: 80
 ---

 <!-- overview -->
@@ -46,10 +46,13 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.

 이를 변경한 후에 다음을 실행해서
+
 ```bash
 kubectl get componentstatuses
 ```
+
 kube-scheduler 컴포넌트가 정상인지 확인할 수 있다. 출력은 다음과 유사하다.
+
 ```
 NAME                 STATUS    MESSAGE             ERROR
 controller-manager   Healthy   ok
@@ -103,7 +103,7 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
 ------------------------------ | ------------ |
 RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
 인증 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
-애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
 파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
 서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/
@@ -150,4 +150,4 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
 * [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)
 * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
-* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)
+* [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
@@ -225,7 +225,7 @@ Address 1: 10.0.162.149

 * https에 대한 자체 서명한 인증서 (신원 인증서를 가지고 있지 않은 경우)
 * 인증서를 사용하도록 구성된 nginx 서버
-* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/docs/concepts/configuration/secret/)
+* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/)

 [nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:

@@ -419,6 +419,6 @@ LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
 ## {{% heading "whatsnext" %}}


-* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
+* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/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/)를 더 자세히 알아본다.
@@ -43,6 +43,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요

   * kube-apiserver:
      * `--feature-gates="IPv6DualStack=true"`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
   * kube-controller-manager:
      * `--feature-gates="IPv6DualStack=true"`
      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
@@ -104,4 +105,4 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급
 ## {{% heading "whatsnext" %}}


-* [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹
+* [IPv4/IPv6 이중 스택 확인](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
@@ -491,8 +491,6 @@ Events:

 장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
 자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다.
-페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)를
-참조할 수 있다.

 ## 대안

@@ -1176,7 +1176,7 @@ HTTP / HTTPS 서비스를 노출할 수도 있다.

 ### PROXY 프로토콜

-클라우드 공급자가 지원하는 경우에 (예: [AWS](/ko/docs/concepts/cluster-administration/cloud-providers/#aws)),
+클라우드 공급자가 지원하는 경우에,
 LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에
 로드 밸런서를 구성할 수 있으며, 이때 접두사가
 [PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다.
@@ -210,8 +210,7 @@ CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를
 ### cinder {#cinder}

 {{< note >}}
-전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. 클라우드 공급자
-구성에 대해서는 [오픈스택 클라우드 공급자](/ko/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다.
+전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스.
 {{< /note >}}

 `cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다.
@@ -1035,7 +1034,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
 업데이트를 수신하지 못한다.
 {{< /note >}}

-시크릿에 대해서 [여기](/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다.
+시크릿에 대해서 [여기](/ko/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다.

 ### storageOS {#storageos}

@@ -344,7 +344,7 @@ spec:

 |                            패턴                                   | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정하지 않은 앱을 사용하는가? |  Kube 1.1에서 작동하는가? |
 | -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
-| [잡 템플릿 확장](/docs/tasks/job/parallel-processing-expansion/)            |                   |                             |          ✓          |          ✓          |
+| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/)            |                   |                             |          ✓          |          ✓          |
 | [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/)   |         ✓         |                             |      때때로      |          ✓          |
 | [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/)  |         ✓         |             ✓               |                     |          ✓          |
 | 정적 작업이 할당된 단일 잡                               |         ✓         |                             |          ✓          |                     |
@@ -360,7 +360,7 @@ spec:

 |                             패턴                                  | `.spec.completions` |  `.spec.parallelism` |
 | -------------------------------------------------------------------- |:-------------------:|:--------------------:|
-| [잡 템플릿 확장](/docs/tasks/job/parallel-processing-expansion/)           |          1          |     1이어야 함      |
+| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/)           |          1          |     1이어야 함      |
 | [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/)   |          W          |        any           |
 | [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/)  |          1          |        any           |
 | 정적 작업이 할당된 단일 잡                               |          W          |        any           |
@@ -124,7 +124,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo

 ### 파드와 컨트롤러

-워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는
+워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는
 파드 장애 시 복제 및 롤아웃과 자동 복구를
 처리한다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중지했음을
 인식하고 대체 파드를 생성한다. 스케줄러는
@@ -142,9 +142,9 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 _파드 템플릿_ 에서 파드를 생성하고 사용자 대신 해당 파드를 관리한다.

 파드템플릿(PodTemplate)은 파드를 생성하기 위한 명세이며,
-[디플로이먼트](/docs/concepts/workloads/controllers/deployment/),
-[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/) 및
-[데몬셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함된다.
+[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/),
+[잡](/ko/docs/concepts/workloads/controllers/job/) 및
+[데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함된다.

 워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 `PodTemplate` 을
 사용하여 실제 파드를 생성한다. `PodTemplate` 은 앱을 실행하는 데 사용되는 워크로드 리소스가
@@ -91,7 +91,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되

 전체 파드의 [단계](#파드의-단계)뿐 아니라, 쿠버네티스는 파드 내부의
 각 컨테이너 상태를 추적한다.
-[컨테이너 라이프사이클 훅(hook)](/docs/concepts/containers/container-lifecycle-hooks/)을
+[컨테이너 라이프사이클 훅(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)을
 사용하여 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있다.

 일단 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}가
@@ -437,7 +437,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
 * [활성, 준비성 및 스타트업 프로브 설정](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)하는
  핸즈온 연습을 해보자.

-* [컨테이너 라이프사이클 훅](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자.
+* [컨테이너 라이프사이클 훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자.

 * API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
 그리고
@@ -125,9 +125,9 @@ weight: 10
 기존에 번역된 문서를 참고한다.

 {{% note %}}
-한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 1회 적용하고 이후에는 한글만 표기한다.
-한영 병기의 대상에는 제목도 포함되므로 제목에 한영 병기가 제공된 경우, 문서 내부에는
-한글만 표기한다.
+한영 병기는 페이지 내에서 해당 용어가 처음 사용될 때, 1회 적용하고 이후에는 한글만 표기한다.
+그러나 필요(예: 자연스러움, 명확성 향상 등)에 따라 추가적인 한영 병기를 허용한다.
+한영 병기의 대상에는 제목도 포함된다.
 {{% /note %}}

 ### API 오브젝트 용어 한글화 방침
@@ -16,7 +16,7 @@ SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites

 PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.

- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)를 참고한다.
+- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다.
 - [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
  - 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다.
 - PR 기여자들이 [CLA]()에 서명했는지 확인한다.
@@ -65,7 +65,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
 최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른
 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다.

-1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해줄 두 명의
+1. 멤버십을 [후원](/ko/docs/contribute/advanced#새로운-기여자-후원)해줄 두 명의
   [리뷰어](#리뷰어) 또는 [승인자](#승인자)를
   찾는다.

@@ -1,28 +1,9 @@
 ---
-title: 쿠버네티스 문서의 버전 지원
-content_type: concept
+title: 사용 가능한 문서의 버전
+content_type: custom
+layout: supported-versions
 card:
  name: about
  weight: 10
-  title: 문서의 버전 지원
+  title: 사용 가능한 문서 버전
 ---
-
-<!-- overview -->
-
-이 웹 사이트에는 현재 버전의 쿠버네티스와 이전 4개 버전의
-쿠버네티스에 대한 문서가 포함되어 있습니다.
-
-
-
-<!-- body -->
-
-## 현재 버전
-
-현재 버전은
-[{{< param "version" >}}](/).
-
-## 이전 버전
-
-{{< versions-other >}}
-
-
@@ -43,7 +43,7 @@ content_type: concept
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
-  * [kube-scheduler 정책](/docs/reference/scheduling/policies)
+  * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
  * [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)

 ## 설계 문서
@@ -0,0 +1,4 @@
+---
+title: API 접근하기
+weight: 20
+---
@@ -0,0 +1,201 @@
+---
+title: 인가 개요
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한
+쿠버네티스 인가에 대해 자세히 알아보자.
+
+
+<!-- body -->
+쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
+인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)를
+참고한다.
+
+쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
+이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는
+기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과
+연동된다는 것을 의미한다.
+
+## 요청 허용 또는 거부 결정
+쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다.
+모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다.
+계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다.
+이는 기본적으로 승인이 거부된다는 것을 의미한다.
+
+(쿠버네티스는 API 서버를 사용하지만,
+특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은
+어드미션 컨트롤러에 의해 처리된다.)
+
+여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다.
+어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다.
+모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다.
+요청 거부는 HTTP 상태 코드 403을 반환한다.
+
+## 요청 속성 검토
+쿠버네티스는 다음 API 요청 속성만 검토한다.
+
+ * **user** - 인증 중에 제공된 `user` 문자열.
+ * **group** - 인증된 사용자가 속한 그룹 이름 목록.
+ * **extra** - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
+ * **API** - 요청이 API 리소스에 대한 것인지 여부.
+ * **Request path** - `/api` 또는 `/healthz`와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
+ * **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)을 참고한다.
+ * **HTTP request verb** - `get`, `post`, `put`, `delete`처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
+ * **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
+ * **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
+ * **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
+ * **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/concepts/overview/kubernetes-api/)을 지정한다.
+
+## 요청 동사 결정
+
+**리소스가 아닌 요청**
+`/api/v1/...` 또는 `/apis/<group>/<version>/...` 이외에 다른 엔드포인트에 대한 요청은
+"리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다.
+예를 들어, `/api` 또는 `/healthz`와 같은 엔드포인트에 대한 `GET` 요청은 `get`을 동사로 사용할 것이다.
+
+**리소스 요청**
+리소스 API 엔드포인트에 대한 요청 동사를 결정하려면
+사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를
+검토한다.
+
+HTTP 동사 | 요청 동사
+----------|---------------
+POST      | create
+GET, HEAD | get(개별 리소스), list(전체 오브젝트 내용을 포함한 리소스 모음), watch(개별 리소스 또는 리소스 모음을 주시)
+PUT       | update
+PATCH     | patch
+DELETE    | delete(개별 리소스), deletecollection(리소스 모음)
+
+쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
+
+* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)
+  * `policy` API 그룹의 `podsecuritypolicies` 리소스에 대한 `use` 동사.
+* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
+  * `rbac.authorization.k8s.io` API 그룹의 `roles` 및 `clusterroles` 리소스에 대한 `bind` 동사.
+* [인증](/docs/reference/access-authn-authz/authentication/)
+  * 핵심 API 그룹의 `users`, `groups`, `serviceaccounts`와 `authentication.k8s.io` API 그룹의 `userextras` 동사.
+
+## 인가 모드 {#authorization-modules}
+
+쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.
+
+ * **Node** - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 [Node 인가](/docs/reference/access-authn-authz/node/)을 참조한다.
+ * **ABAC** - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 [ABAC 모드](/docs/reference/access-authn-authz/abac/)를 참조한다.
+ * **RBAC** - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 [RBAC 모드](/docs/reference/access-authn-authz/rbac/)를 참조한다.
+   * 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 `rbac.authorization.k8s.io` API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.
+   * RBAC을 활성화하려면 `--authorization-mode=RBAC`로 API 서버를 시작한다.
+ * **Webhook** - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 [Webhook 모드](/docs/reference/access-authn-authz/webhook/)를 참조한다.
+
+#### API 접근 확인
+
+`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다.
+이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며,
+사용되는 인가 모드에 관계없이 작동한다.
+
+
+```bash
+kubectl auth can-i create deployments --namespace dev
+```
+```
+yes
+```
+
+```shell
+kubectl auth can-i create deployments --namespace prod
+```
+```
+no
+```
+
+관리자는 이를 [사용자 가장(impersonation)](/docs/reference/access-authn-authz/authentication/#user-impersonation)과
+병행하여 다른 사용자가 수행할 수 있는 작업을 결정할 수 있다.
+
+```bash
+kubectl auth can-i list secrets --namespace dev --as dave
+```
+```
+no
+```
+
+`SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서
+API 서버 인가를 외부 서비스에 노출시킨다.
+이 그룹의 기타 리소스에는 다음이 포함된다.
+
+* `SubjectAccessReview` - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다.
+* `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다.
+* `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.
+
+이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인
+일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.
+
+```bash
+kubectl create -f - -o yaml << EOF
+apiVersion: authorization.k8s.io/v1
+kind: SelfSubjectAccessReview
+spec:
+  resourceAttributes:
+    group: apps
+    resource: deployments
+    verb: create
+    namespace: dev
+EOF
+```
+
+생성된 `SelfSubjectAccessReview` 는 다음과 같다.
+```
+apiVersion: authorization.k8s.io/v1
+kind: SelfSubjectAccessReview
+metadata:
+  creationTimestamp: null
+spec:
+  resourceAttributes:
+    group: apps
+    resource: deployments
+    namespace: dev
+    verb: create
+status:
+  allowed: true
+  denied: false
+```
+
+## 인가 모듈에 플래그 사용
+
+정책에 포함된 인가 모듈을 나타내기 위해
+정책에 플래그를 포함시켜야 한다.
+
+다음 플래그를 사용할 수 있다.
+
+  * `--authorization-mode=ABAC` 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다.
+  * `--authorization-mode=RBAC` 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다.
+  * `--authorization-mode=Webhook` WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다.
+  * `--authorization-mode=Node` 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다.
+  * `--authorization-mode=AlwaysDeny` 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다.
+  * `--authorization-mode=AlwaysAllow` 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.
+
+하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에
+우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
+
+## 파드 생성을 통한 권한 확대
+
+네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는
+해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다.
+네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다.
+사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나
+서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.
+
+{{< caution >}}
+시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다.
+네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는
+네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고
+네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다.
+이는 인가 모드에 관계없이 적용된다.
+{{< /caution >}}
+
+
+## {{% heading "whatsnext" %}}
+
+* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
+* 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다.
@@ -0,0 +1,162 @@
+---
+title: 쿠버네티스 API 접근 제어하기
+content_type: concept
+weight: 5
+---
+
+<!-- overview -->
+이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.
+
+
+<!-- body -->
+사용자는 `kubectl`, 클라이언트 라이브러리
+또는 REST 요청을 통해
+[API에 접근한다](/docs/tasks/access-application-cluster/access-cluster/).
+사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
+요청이 API에 도달하면,
+다음 다이어그램에 설명된 몇 가지 단계를 거친다.
+
+![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
+
+## 전송 보안
+
+일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
+API 서버는 인증서를 제시한다.
+이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
+API 서버의 인증서에 대한 루트 인증서를 포함하며,
+시스템 기본 루트 인증서 대신 사용된다.
+`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
+이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
+클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
+
+## 인증
+
+TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
+이는 다이어그램에 **1**단계로 표시되어 있다.
+클러스터 생성 스크립트 또는 클러스터 관리자는
+API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
+인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
+
+인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
+일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
+
+인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
+JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
+
+여러 개의 인증 모듈을 지정할 수 있으며,
+이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
+
+GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
+
+요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
+이 외에는 사용자가 특정 `username`으로 인증되며,
+이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
+일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면,
+이외의 인증기는 그렇지 않다.
+
+쿠버네티스는 접근 제어 결정과 요청 기록 시 `usernames`를 사용하지만,
+`user` 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를
+오브젝트 저장소에 저장하지도 않는다.
+
+## 인가
+
+특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 **2**단계로 표시되어 있다.
+
+요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
+
+예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 `projectCaribou` 네임스페이스에서만 파드를 읽을 수 있다.
+
+```json
+{
+    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
+    "kind": "Policy",
+    "spec": {
+        "user": "bob",
+        "namespace": "projectCaribou",
+        "resource": "pods",
+        "readonly": true
+    }
+}
+```
+Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의 오브젝트를 읽을 수 있기 때문에 요청이 인가된다.
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "projectCaribou",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    }
+  }
+}
+```
+Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.
+
+쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
+
+쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
+
+인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/docs/reference/access-authz/authorization/)를 참조한다.
+
+
+## 어드미션 제어
+
+어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다.
+인가 모듈에서 사용할 수 있는 속성 외에도
+어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
+
+어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
+어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
+여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
+
+이는 다이어그램에 **3**단계로 표시되어 있다.
+
+인증 및 인가 모듈과 달리,
+어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
+
+어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도
+필드의 복잡한 기본값을 설정할 수 있다.
+
+사용 가능한 어드미션 제어 모듈은 [여기](/docs/reference/access-authn-authz/admission-controllers/)에 서술되어 있다.
+
+요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
+오브젝트 저장소에 기록(**4**단계)된다.
+
+
+## API 서버 포트와 IP
+
+이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
+API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
+
+기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
+
+  1. `로컬호스트 포트`:
+
+      - 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
+        (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
+      - TLS가 없다.
+      - 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다.
+      - 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
+      - 요청이 인증 및 인가 모듈을 **우회한다**.
+      - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
+      - 호스트 접근 요구로부터 보호를 받는다.
+
+  2. `보안 포트`:
+
+      - 가능한 항상 사용하는 것이 좋다.
+      - TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
+      - 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
+      - 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
+      - 요청이 인증 및 인가 모듈에 의해 처리된다.
+      - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
+      - 인증 및 인가 모듈을 실행한다.
+
+GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
+API 서버는 포트 443에서 서비스한다.
+GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
+이외에 클러스터 설정 방법은 다양하다.
+
@@ -0,0 +1,112 @@
+---
+title: 서비스 어카운트 관리하기
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
+독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
+
+인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
+가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.
+
+
+<!-- body -->
+## 사용자 어카운트와 서비스 어카운트 비교
+
+쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
+구분한다.
+
+  - 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
+    위한 것이다.
+  - 사용자 어카운트는 전역을 대상으로 고려된다.
+    클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다.
+    서비스 어카운트는 네임스페이스에 할당된다.
+  - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
+    여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
+    서비스 어카운트 생성은
+    클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록
+    보다 가볍게 만들어졌다.
+  - 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
+  - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
+    서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에
+    이러한 설정은 이식성이 좋다.
+
+## 서비스 어카운트 자동화
+
+서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
+
+  - 서비스 어카운트 어드미션 컨트롤러
+  - 토큰 컨트롤러
+  - 서비스 어카운트 컨트롤러
+
+### 서비스 어카운트 어드미션 컨트롤러
+
+파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
+라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다.
+파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
+이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
+
+  1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다.
+  1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다.
+  1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다.
+  1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
+  1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다.
+
+v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
+서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
+[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다.
+
+### 토큰 컨트롤러
+
+토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
+
+- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다.
+- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다.
+- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다.
+- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다.
+
+서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다.
+개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
+마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다.
+공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.
+
+#### 추가적인 API 토큰 생성
+
+컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다.
+서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해
+서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면
+컨트롤러가 새로 생성된 토큰으로 갱신한다.
+
+secret.json:
+
+```json
+{
+    "kind": "Secret",
+    "apiVersion": "v1",
+    "metadata": {
+        "name": "mysecretname",
+        "annotations": {
+            "kubernetes.io/service-account.name": "myserviceaccount"
+        }
+    },
+    "type": "kubernetes.io/service-account-token"
+}
+```
+
+```shell
+kubectl create -f ./secret.json
+kubectl describe secret mysecretname
+```
+
+#### 서비스 어카운트 토큰 삭제/무효화
+
+```shell
+kubectl delete secret mysecretname
+```
+
+### 서비스 어카운트 컨트롤러
+
+서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고
+"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
@@ -366,13 +366,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의
  `DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다.
 - `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`) 리소스를 청크(chunks)로 검색할 수 있도록 한다.
- `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
+- `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
 - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
 - `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
   자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
 - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
  대한 제한을 보고하도록 한다.
-   자세한 내용은 [동적 볼륨 제한](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)을 참고한다.
+   자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
 - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
  포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
  더 가까운 노드가 선호된다.
@@ -423,7 +423,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
  생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
  실행 중인 파드 문제를 해결한다.
- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/docs/concepts/cluster-administration/monitoring.md).
+- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/).
 - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
  기반 리소스 프로비저닝을 활성화한다.
 - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
@@ -2,7 +2,6 @@
 title: 클라우드 공급자
 id: cloud-provider
 date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
 short_description: >
  클라우드 컴퓨팅 플랫폼을 제공하는 조직.

@@ -26,6 +25,6 @@ Infrastructure as a Service 또는 IaaS 라 부른다).

 사용자는 쿠버네티스를 관리되는 서비스로 찾을 수 있다. 때로는 이것을
 Platform as a Service 또는 PaaS라 부른다. 관리되는 쿠버네티스를 사용하면
-클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라, 
+클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라,
 노드와 연관되는 인프라(네트워킹, 스토리지 그리고 로드밸런서와 같은 기타 요소)
 를 책임진다.
@@ -38,6 +38,8 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.

 ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리

+{{% thirdparty-content %}}
+
 다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌
 각각의 저자들이 제공하고 관리한다.

@@ -29,7 +29,7 @@ weight: 40
 * [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 위한 클라이언트와 서버 인증서

 {{< note >}}
-`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
+`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
 {{< /note >}}

 etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
@@ -120,8 +120,8 @@ kubeadm 사용자만 해당:

 | 개인키 경로             | 공개 키 경로             | 명령어                 | 파라미터                             |
 |------------------------------|-----------------------------|-------------------------|--------------------------------------|
-|  sa.key                      |                             | kube-controller-manager | --service-account-private-key-file              |
-|                              | sa.pub                      | kube-apiserver          | --service-account-key-file                  |
+|  sa.key                      |                             | kube-controller-manager | --service-account-private-key-file   |
+|                              | sa.pub                      | kube-apiserver          | --service-account-key-file           |

 ## 각 사용자 계정을 위한 인증서 설정하기

@@ -157,4 +157,3 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 | kubelet.conf            | kubelet                 | 클러스터 각 노드를 위해 필요하다.                            |
 | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. |
 | scheduler.conf          | kube-scheduler          | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다.          |
-
@@ -447,11 +447,11 @@ spec:

 | Driver | OS | HostFolder | VM |
 | --- | --- | --- | --- |
-| VirtualBox | 리눅스 | /home | /hosthome |
-| VirtualBox | macOS | /Users | /Users |
-| VirtualBox | 윈도우 | C://Users | /c/Users |
-| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
-| Xhyve | macOS | /Users | /Users |
+| VirtualBox | 리눅스 | `/home` | `/hosthome` |
+| VirtualBox | macOS | `/Users` | `/Users` |
+| VirtualBox | 윈도우 | `C://Users` | `/c/Users` |
+| VMware Fusion | macOS | `/Users` | `/mnt/hgfs/Users` |
+| Xhyve | macOS | `/Users` | `/Users` |

 ## 프라이빗 컨테이너 레지스트리

@@ -1,4 +0,0 @@
---
-title: 온-프레미스 VM
-weight: 40
---
@@ -0,0 +1,680 @@
+---
+title: 쿠버네티스의 윈도우 지원 소개
+content_type: concept
+weight: 65
+---
+
+<!-- overview -->
+
+윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. [윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다.
+
+
+
+<!-- body -->
+
+## 쿠버네티스의 윈도우 컨테이너
+
+쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 [파드](/ko/docs/concepts/workloads/pods/pod-overview/)에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다.
+
+윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다.
+
+{{< note >}}
+[마스터 컴포넌트](/ko/docs/concepts/overview/components/)를 포함한 쿠버네티스 컨트롤 플레인은 리눅스에서 계속 실행된다. 윈도우 전용 쿠버네티스 클러스터는 계획이 없다.
+{{< /note >}}
+
+{{< note >}}
+이 문서에서 윈도우 컨테이너에 대해 이야기할 때 프로세스 격리된 윈도우 컨테이너를 의미한다. [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)가 있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다.
+{{< /note >}}
+
+## 지원되는 기능 및 제한
+
+### 지원되는 기능
+
+#### 윈도우 OS 버전 지원
+
+쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다.
+
+| 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
+| --- | --- | --- | --- |
+| *Kubernetes v1.14* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.15* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.16* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 |
+| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
+
+{{< note >}}
+지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다.
+{{< /note >}}
+{{< note >}}
+모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
+{{< /note >}}
+{{< note >}}
+윈도우 서버 호스트 운영 체제에는 [윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 [윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다.
+{{< /note >}}
+{{< note >}}
+프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, [여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다.
+{{< /note >}}
+
+#### 컴퓨트
+
+API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 [제한 섹션](#제한)에 요약된 주요 기능에는 몇 가지 눈에 띄는 차이점이 있다.
+
+윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다.
+
+* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
+
+    파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.
+
+  * 프로세스 분리 및 볼륨 공유 기능을 갖춘 파드 당 하나 또는 여러 개의 컨테이너
+  * 파드 상태 필드
+  * 준비성(readiness) 및 활성 프로브(liveness probe)
+  * postStart 및 preStop 컨테이너 라이프사이클 이벤트
+  * 컨피그맵(ConfigMap), 시크릿(Secrets): 환경 변수 또는 볼륨으로
+  * EmptyDir
+  * 명명된 파이프 호스트 마운트
+  * 리소스 제한
+* [컨트롤러](/ko/docs/concepts/workloads/controllers/)
+
+    쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다.
+
+  * 레플리카셋(ReplicaSet)
+  * 레플리케이션컨트롤러(ReplicationController)
+  * 디플로이먼트(Deployment)
+  * 스테이트풀셋(StatefulSet)	
+  * 데몬셋(DaemonSet)
+  * 잡(Job)
+  * 크론잡(CronJob)
+* [서비스](/ko/docs/concepts/services-networking/service/)
+
+    쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 다음의 유형, 속성 및 기능을 활용할 수 있다.
+
+  * 서비스 환경 변수
+  * 노드포트(NodePort)
+  * 클러스터IP(ClusterIP)
+  * 로드밸런서(LoadBalancer)
+  * ExternalName
+  * 헤드리스 서비스(Headless services)
+
+파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 충분하지 않다. 다음 기능에 대한 지원이 추가되었다.
+
+* 파드와 컨테이너 메트릭
+* Horizontal Pod Autoscaler 지원
+* kubectl Exec
+* 리소스쿼터(Resource Quotas)
+* 스케쥴러 선점(preemption)
+
+#### 컨테이너 런타임
+
+##### Docker EE
+
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+
+Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다.
+
+##### CRI-ContainerD
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+{{< caution >}}
+커널 패치가 필요한 윈도우 네트워크 공유에 접근하기 위해 ContainerD와 함께 GMSA를 사용할 때 [알려진 제한](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있다. [Microsoft 윈도우 컨테이너 이슈 트래커](https://github.com/microsoft/Windows-Containers/issues/44)에서 업데이트를 확인한다.
+{{< /caution >}}
+
+{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0-beta.2+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다.
+
+쿠버네티스 v1.18은 윈도우에서 ContainerD에 대한 초기 지원을 추가한다. 윈도우에서 ContainerD의 진행 상황은 [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001)에서 확인할 수 있다.
+
+[윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) 방법을 확인한다.
+
+#### 퍼시스턴트 스토리지(Persistent Storage)
+
+쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 [플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다.
+
+##### 인-트리(In-tree) 볼륨 플러그인
+인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다.
+
+* [awsElasticBlockStore](/ko/docs/concepts/storage/volumes/#awselasticblockstore)
+* [azureDisk](/ko/docs/concepts/storage/volumes/#azuredisk)
+* [azureFile](/ko/docs/concepts/storage/volumes/#azurefile)
+* [gcePersistentDisk](/ko/docs/concepts/storage/volumes/#gcepersistentdisk)
+* [vsphereVolume](/ko/docs/concepts/storage/volumes/#vspherevolume)
+
+##### FlexVolume 플러그인
+[FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다.
+
+* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
+* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
+
+##### CSI 플러그인
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 플러그인으로 구성된다.
+
+CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 다양한 특권이 필요한(privileged) 작업을 수행해야 한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, 각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 사용하여 지원된다. 자세한 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다.
+
+#### 네트워킹
+
+윈도우 컨테이너용 네트워킹은 [CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다. 윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다.
+
+* 가상 네트워크(vSwitch 생성 포함)
+* 엔드포인트 / vNIC
+* 네임스페이스
+* 정책(패킷 캡슐화, 로드 밸런싱 규칙, ACL, NAT 규칙 등)
+
+다음의 서비스 사양 유형이 지원된다.
+
+* NodePort
+* ClusterIP
+* LoadBalancer
+* ExternalName
+
+##### 네트워크 모드
+윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다.
+
+| 네트워크 드라이버 | 설명 | 컨테이너 패킷 수정 | 네트워크 플러그인 | 네트워크 플러그인 특성 |
+| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
+| L2bridge | 컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. | MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 호스트 IP에 다시 쓰여질 수 있다. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel 호스트 게이트웨이는 win-bridge를 사용한다. | win-bridge는 L2bridge 네트워크 모드를 사용하고, 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. |
+| L2Tunnel | 이것은 l2bridge의 특별한 케이스이지만 Azure에서만 사용된다. 모든 패킷은 SDN 정책이 적용되는 가상화 호스트로 전송된다. | MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, [Azure Virtual Network에서 제공하는](https://azure.microsoft.com/ko-kr/services/virtual-network/) 기능 집합을 활용할 수 있다. 예를 들어 Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. [azure-cni 예제](https://docs.microsoft.com/ko-kr/azure/aks/concepts-network#azure-cni-advanced-networking)를 참고한다. |
+| 오버레이(쿠버네티스에서 윈도우용 오버레이 네트워킹은 *알파* 단계에 있음) | 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. | 외부 헤더로 캡슐화된다. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN(win-overlay 사용) | win-overlay는 가상 컨테이너 네트워크를 호스트의 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 윈도우 서버 2019에서 [KB4489899](https://support.microsoft.com/help/4489899)가 필요하다. |
+| Transparent([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)의 특수한 유스케이스) | 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다. | 패킷은 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 또는 [STT](https://datatracker.ietf.org/doc/draft-davie-stt)를 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다. <br/> 패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. <br/> NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible을 통해 배포](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)한다. 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 iptables/netsh를 사용하지 않고 수행된다. |
+| NAT(*쿠버네티스에서 사용되지 않음*) | 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)라는 내부 컴포넌트를 사용하여 제공된다. | MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 완전성을 위해 여기에 포함되었다. |
+
+위에서 설명한대로 [플라넬(Flannel)](https://github.com/coreos/flannel) CNI [메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 [VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**alpha 지원**, win-overlay에 위임) 및 [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (안정적인 지원, win-bridge에 위임)를 통해 [윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다.
+
+노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다.
+
+* 파드 -> 파드(IP)
+* 파드 -> 파드(Name)
+* 파드 -> 서비스(Cluster IP)
+* 파드 -> 서비스(PQDN, 단 "."이 없는 경우에만)
+* 파드 -> 서비스(FQDN)
+* 파드 -> External(IP)
+* 파드 -> External(DNS)
+* 노드 -> 파드
+* 파드 -> 노드
+
+##### IP 주소 관리(IPAM) {#ipam}
+윈도우에서는 다음 IPAM 옵션이 지원된다.
+
+* [호스트-로컬](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
+* HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다) 
+* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cni 전용)
+
+##### 로드 밸런싱과 서비스
+
+윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 구성할 수 있다.
+
+{{< table caption="윈도우 서비스 구성" >}}
+| 기능 | 설명 | 지원되는 쿠버네티스 버전 | 지원되는 윈도우 OS 빌드 | 활성화하는 방법 |
+| ------- | ----------- | ----------------------------- | -------------------------- | ------------- |
+| 세션 어피니티 | 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 한다. | v1.19 이상 | [윈도우 서버 vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) 이상 | `service.spec.sessionAffinity`를 "ClientIP"로 설정 |
+| 직접 서버 반환 | IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 설정된 상태로 도착한다. 낮은 지연 시간과 확장성을 약속한다. | v1.15 이상 | 윈도우 서버, 버전 2004 | kube-proxy에서 다음 플래그를 설정한다. `--feature-gates="WinDSR=true" --enable-dsr=true` |
+| 대상 보존(Preserve-Destination) | 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 대상 서비스의 가상 IP를 보존한다. 이 설정은 또한 수신 패킷의 클라이언트 IP가 보존되도록 한다. | v1.15 이상 | 윈도우 서버, 버전 1903 (이상) | 서비스 어느테이션에서 `"preserve-destination": "true"`를 설정하고 kube-proxy에서 DSR 플래그를 활성화한다. |
+| IPv4/IPv6 이중 스택 네트워킹 | 클러스터 내/외부 기본 IPv4-to-IPv4 통신과 함께 IPv6-to-IPv6 통신 | v1.19 이상 | 윈도우 서버 vNext Insider Preview Build 19603(또는 그 이상) | [IPv4/IPv6 이중 스택](#ipv4ipv6-이중-스택)을 참고한다. |
+{{< /table >}}
+
+#### IPv4/IPv6 이중 스택
+`IPv6DualStack` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)을 참조한다.
+
+{{< note >}}
+윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 vNext Insider Preview Build 19603 이상이 필요하다.
+{{< /note >}}
+
+{{< note >}}
+윈도우의 오버레이(VXLAN) 네트워크는 현재 이중 스택 네트워킹을 지원하지 않는다.
+{{< /note >}}
+
+### 제한
+
+#### 컨트롤 플레인
+
+윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.
+
+#### 컴퓨트
+
+##### 리소스 관리 및 프로세스 격리
+
+ 리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다.
+
+##### 운영 체제 제한
+
+윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
+
+##### 기능 제한
+
+* TerminationGracePeriod: 구현되지 않음
+* 단일 파일 매핑: CRI-ContainerD로 구현 예정
+* 종료 메시지: CRI-ContainerD로 구현 예정
+* 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
+* HugePages: 현재 윈도우 컨테이너에서 지원되지 않음
+* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다.
+* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조).
+
+##### 메모리 예약 및 처리
+
+윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다.
+
+2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다. 
+
+오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다. 
+
+플래그의 동작은 아래에 설명된대로 다르게 동작한다.
+
+* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트
+* `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다.
+* `--eviction-hard`와 `--eviction-soft`를 사용한 축출은 구현되지 않았다.
+* MemoryPressure 조건은 구현되지 않았다.
+* kubelet이 취한 OOM 축출 조치가 없다.
+* 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다.
+
+#### 스토리지
+
+윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다.
+
+* 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉터리만 대상으로 할 수 있다.
+* 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다.
+* 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다.
+* 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다.
+
+결과적으로, 다음 스토리지 기능은 윈도우 노드에서 지원되지 않는다.
+
+* 볼륨 하위 경로(subpath) 마운트. 전체 볼륨만 윈도우 컨테이너에 마운트할 수 있다.
+* 시크릿에 대한 하위 경로 볼륨 마운트
+* 호스트 마운트 프로젝션
+* DefaultMode(UID/GID 종속성에 기인함)
+* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 읽기 전용을 지원한다.
+* 블록 디바이스 매핑
+* 저장 매체로서의 메모리
+* uui/guid, 사용자별 리눅스 파일시스템 권한과 같은 파일시스템 기능
+* NFS 기반 스토리지/볼륨 지원
+* 마운트된 볼륨 확장(resizefs)
+
+#### 네트워킹
+
+윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다.
+
+윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다.
+
+다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다.
+
+* 윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다.
+* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서 작동)
+* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다.
+* kube-proxy의 오버레이 네트워킹 지원은 알파 릴리스이다. 또한 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 설치해야 한다.
+* 로컬 트래픽 정책 및 DSR 모드
+* l2bridge, l2tunnel 또는 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이러한 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다.
+* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은 ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다.
+  * 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 ICMP 패킷은 예상대로 제한 없이 작동한다.
+  * TCP/UDP 패킷은 예상대로 제한 없이 작동한다.
+  * 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 소스로 다시 라우팅되지 않는다.
+  * TCP/UDP 패킷은 여전히 치환될 수 있기 때문에 `ping <destination>`을 `curl <destination>`으로 대체하여 외부와의 연결을 디버깅할 수 있다.
+
+해당 기능은 쿠버네티스 v1.15에 추가되었다.
+
+* `kubectl port-forward`
+
+##### CNI 플러그인
+
+* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 현재 "CHECK" 구현 누락으로 인해 [CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0을 구현하지 않는다.
+* Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다.
+
+1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 있는 로컬 파드에서만 가능하다.
+2. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) 백엔드 문서를 참고한다.
+
+##### DNS {#dns-limitations}
+
+* ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다.
+* 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 연결된 DNS 접미사인 DNS 접미사 1개만 있다. 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS 접미사 **default.svc.cluster.local**이 있다. 윈도우 파드에서는 **kubernetes.default.svc.cluster.local** 및 **kubernetes**를 모두 확인할 수 있지만 **kubernetes.default** 또는 **kubernetes.default.svc**와 같은 중간 항목은 확인할 수 없다.
+* 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 사용하는 것이 좋다.
+
+##### IPv6
+윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다.
+
+
+##### 세션 어피니티(affinity)
+`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다.
+
+##### 보안
+
+시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다.
+
+1. 파일 ACL을 사용하여 시크릿 파일 위치를 보호한다.
+2. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용한 볼륨-레벨 암호화를 사용한다.
+
+[RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)는 현재 윈도우에서 지원되지 않는다. 해결 방법(workaround)은 컨테이너를 패키징하기 전에 로컬 계정을 만드는 것이다. RunAsUsername 기능은 향후 릴리스에 추가될 수 있다.
+
+SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다.
+
+또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 않는다.
+
+#### API
+
+대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. 중요한 차이점은 OS와 컨테이너 런타임의 차이로 귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 설계되었다.
+
+높은 수준에서 이러한 OS 개념은 다르다.
+
+* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다.
+* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다.
+* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 일반적으로 두 가지를 모두 허용하고 작동하도록 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
+* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다.
+  * UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다.
+  * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다.
+  * 서비스는 SERVICE_CONTROL_STOP 제어 코드를 수용할 수 있는 Service Control Handler 함수를 등록한다.
+
+종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. 특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다.
+
+##### V1.Container
+
+* V1.Container.ResourceRequirements.limits.cpu 및 V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 스케일된다. [참고: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [참고: Microsoft 문서 내 리소스 제어](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/resource-controls)
+  * Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 [사용자 권한(privilege) 어설트](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가 필요하다.
+* V1.Container.ResourceRequirements.requests.cpu 및 V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 모범 사례로 모든 컨테이너에 적용해야 한다.
+* V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 불가능하며, 어떤 기능도 연결되지 않는다.
+* V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 구현되지 않는다.
+* V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 지원하지 않는다.
+* V1.Container.SecurityContext.procMount - 윈도우에는 /proc 파일시스템이 없다.
+* V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 필요하다.
+* V1.Container.SecurityContext.runAsGroup - 윈도우에서는 불가능하며, GID 지원이 없다.
+* V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 ContainerAdministrator이다.
+* V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID 지원이 없다.
+* V1.Container.SecurityContext.seLinuxOptions - 윈도우에서는 불가능하며, SELinux가 없다.
+* V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 작동한다.
+
+##### V1.Pod
+
+* V1.Pod.hostIPC, v1.pod.hostpid - 윈도우에서 호스트 네임스페이스 공유가 불가능하다.
+* V1.Pod.hostNetwork - 호스트 네트워크를 공유하기 위한 윈도우 OS 지원이 없다.
+* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 지원되지 않는다.
+* V1.Pod.podSecurityContext - 아래 V1.PodSecurityContext 내용을 참고한다.
+* V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다.
+* V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 완전히 구현되지 않았다. [참조](https://github.com/moby/moby/issues/25982)의 내용을 참고한다. 현재 동작은 ENTRYPOINT 프로세스가 CTRL_SHUTDOWN_EVENT로 전송된 다음, 윈도우가 기본적으로 5초를 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다. 5초 기본값은 실제로 [컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다.
+* V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다.
+* V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 TestGrid에 테스트가 있다.
+  * V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다.
+* V1.VolumeMount.mountPropagation - 마운트 전파(propagation)는 윈도우에서 지원되지 않는다.
+
+##### V1.PodSecurityContext
+
+PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 나열한다.
+
+* V1.PodSecurityContext.SELinuxOptions - SELinux는 윈도우에서 사용할 수 없다.
+* V1.PodSecurityContext.RunAsUser - 윈도우에서는 사용할 수 없는 UID를 제공한다.
+* V1.PodSecurityContext.RunAsGroup - 윈도우에서는 사용할 수 없는 GID를 제공한다.
+* V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티인 ContainerAdministrator이다.
+* V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다.
+* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다.
+
+## 도움 받기 및 트러블슈팅 {#troubleshooting}
+
+쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 [섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows [로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다.
+
+1. start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가?
+
+    kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 한다.
+
+1. 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가?
+
+    Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 자동으로 다시 시작하여 복원력(resiliency)을 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 두 가지 옵션이 있다.
+
+    1. 네이티브 윈도우 서비스
+
+        Kubelet와 kube-proxy는 `sc.exe`를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다.
+
+        ```powershell
+        # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성
+        sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>"
+
+        # 인자에 공백이 포함된 경우 이스케이프 되어야 한다.
+        sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>"
+
+        # 서비스 시작
+        Start-Service kubelet
+        Start-Service kube-proxy
+
+        # 서비스 중지
+        Stop-Service kubelet (-Force)
+        Stop-Service kube-proxy (-Force)
+
+        # 서비스 상태 질의
+        Get-Service kubelet
+        Get-Service kube-proxy
+        ```
+
+    1. nssm.exe 사용
+
+        또한 언제든지 [nssm.exe](https://nssm.cc/)와 같은 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, kube-proxy)를 실행할 수 있다. 이 [샘플 스크립트](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)를 사용하여 백그라운드에서 윈도우 서비스로 실행하기 위해 nssm.exe를 활용하여 kubelet, kube-proxy, flanneld.exe를 등록할 수 있다.
+
+        ```powershell
+        register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP <Kube-dns 서비스 IP> -LogDir <로그 위치 디렉터리>
+
+        # NetworkMode      = 네트워크 모드 l2bridge(flannel host-gw, 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan)
+        # ManagementIP     = 윈도우 노드에 할당된 IP 주소. ipconfig를 사용하여 찾을 수 있다.
+        # ClusterCIDR      = 클러스터 서브넷 범위. (기본값 10.244.0.0/16)
+        # KubeDnsServiceIP = 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10)
+        # LogDir           = kubelet 및 kube-proxy 로그가 각각의 출력 파일로 리다이렉션되는 디렉터리(기본값 C:\k)
+        ```
+
+        위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 nssm.exe를 수동으로 구성할 수 있다.
+        ```powershell
+        # flanneld.exe 등록
+        nssm install flanneld C:\flannel\flanneld.exe
+        nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1
+        nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname>
+        nssm set flanneld AppDirectory C:\flannel
+        nssm start flanneld
+
+        # kubelet.exe 등록
+        # Microsoft는 mcr.microsoft.com/k8s/core/pause:1.2.0에서 pause 인프라 컨테이너를 릴리스했다.
+        nssm install kubelet C:\k\kubelet.exe
+        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+        nssm set kubelet AppDirectory C:\k
+        nssm start kubelet
+
+        # kube-proxy.exe 등록 (l2bridge / host-gw)
+        nssm install kube-proxy C:\k\kube-proxy.exe
+        nssm set kube-proxy AppDirectory c:\k
+        nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false
+        nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
+        nssm set kube-proxy DependOnService kubelet
+        nssm start kube-proxy
+
+        # kube-proxy.exe 등록 (overlay / vxlan)
+        nssm install kube-proxy C:\k\kube-proxy.exe
+        nssm set kube-proxy AppDirectory c:\k
+        nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
+        nssm set kube-proxy DependOnService kubelet
+        nssm start kube-proxy
+        ```
+
+
+        초기 트러블슈팅을 위해 [nssm.exe](https://nssm.cc/)에서 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다.
+
+        ```powershell
+        nssm set <Service Name> AppStdout C:\k\mysvc.log
+        nssm set <Service Name> AppStderr C:\k\mysvc.log
+        ```
+
+        자세한 내용은 공식 [nssm 사용](https://nssm.cc/usage) 문서를 참고한다.
+
+1. 내 윈도우 파드에 네트워크 연결이 없다.
+
+    가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 활성화되어 있는지 확인한다.
+
+1. 내 윈도우 파드가 외부 리소스를 ping 할 수 없다.
+
+    윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, `ping <IP>`를 해당 `curl <IP>`명령으로 대체한다.
+
+    여전히 문제가 발생하는 경우, [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다.
+
+    쿠버네티스 네트워킹 요구 사항 중 하나([쿠버네티스 모델](/ko/docs/concepts/cluster-administration/networking/))는 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 `cni.conf`의 ExceptionList는 다음과 같아야 한다.
+
+    ```conf
+    "ExceptionList": [
+                    "10.244.0.0/16",  # 클러스터 서브넷
+                    "10.96.0.0/12",   # 서비스 서브넷
+                    "10.127.130.0/24" # 관리(호스트) 서브넷
+                ]
+    ```
+
+1. 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다.
+
+    노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다.
+
+1. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다.
+
+    이 문제는 `hostname-override` 파라미터가 [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.
+
+    ```powershell
+    C:\k\kube-proxy.exe --hostname-override=$(hostname)
+    ```
+
+1. 플라넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다.
+
+    이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다.
+
+    ```powershell
+    Remove-Item C:\k\SourceVip.json
+    Remove-Item C:\k\SourceVipRequest.json
+    ```
+
+1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다.
+
+    이 [조사 중인 이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때 타이밍 이슈일 가능성이 높다. 해결 방법은 간단히 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다.
+
+    ```powershell
+    PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
+    PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
+    ```
+
+1. `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다.
+
+    이것은 플라넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 `/run/flannel/subnet.env`에서 윈도우 워커 노드의 `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다.
+
+    ```env
+    FLANNEL_NETWORK=10.244.0.0/16
+    FLANNEL_SUBNET=10.244.4.1/24
+    FLANNEL_MTU=1500
+    FLANNEL_IPMASQ=true
+    ```
+
+1. 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다.
+
+    이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다.
+
+1. kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다.
+
+    윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다.
+
+    ```powershell
+    Get-HnsNetwork | ? Name -ieq "cbr0"
+    Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
+    ```
+
+    호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
+
+1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
+
+    pause 이미지가 OS 버전과 호환되는지 확인한다. [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다.
+
+    쿠버네티스 v1.14부터 Microsoft는 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 pause 인프라 컨테이너를 릴리스한다.
+
+1. DNS 확인(resolution)이 제대로 작동하지 않는다.
+
+    이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다.
+    
+1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.
+
+    이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
+    자체 pause 인프라 컨테이너를 빌드하려면 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다.
+
+1. 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다.
+
+    프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 정의해야 한다.
+
+    ```PowerShell
+    [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+    [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+    ```
+
+1. `pause` 컨테이너란 무엇인가?
+
+    쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다.
+
+    "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 참고한다.
+
+### 추가 조사
+
+이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는데 도움을 받을 수 있다.
+
+* 스택오버플로우 [윈도우 서버 컨테이너](https://stackoverflow.com/questions/tagged/windows-server-container) 주제
+* 쿠버네티스 공식 포럼 [discuss.kubernetes.io](https://discuss.kubernetes.io/)
+* 쿠버네티스 슬랙 [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
+
+## 이슈 리포팅 및 기능 요청
+
+버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면, [GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 활용한다. [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)에서 이슈를 열고 SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 이슈에 대한 경험을 언급하고 추가 로그를 첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다.
+
+버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 포함한다.
+
+* 쿠버네티스 버전: kubectl version
+* 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 구성, 도커 버전
+* 문제를 재현하기 위한 세부 단계
+* [관련 로그](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
+* SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 이슈에 sig/windows 태그를 지정한다.
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+로드맵에는 많은 기능이 있다. 요약된 높은 수준의 목록이 아래에 포함되어 있지만, [로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 [기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 윈도우 지원을 개선하는데 도움이 주는 것이 좋다.
+
+### Hyper-V 격리(isolation)
+
+쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 Hyper-V 격리가 필요하다.
+
+* 추가 보안을 위해 파드 간 하이퍼바이저 기반 격리
+* 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 최신 윈도우 서버 버전을 실행할 수 있다.
+* 파드에 대한 특정 CPU/NUMA 설정
+* 메모리 격리 및 예약
+
+v1.10의 실험적(experimental) 기능인 기존 Hyper-V 격리 지원은 위에서 언급한 CRI-ContainerD와 런타임클래스(RuntimeClass) 기능을 위해 향후 사용 중단(deprecated)된다. 현재 기능을 사용하고 Hyper-V 격리된 컨테이너를 만들려면, kubelet을 기능 게이트(feature gates) `HyperVContainer=true`로 시작해야 하고 파드에 `experimental.windows.kubernetes.io/isolation-type=hyperv` 어노테이션을 포함해야 한다. 실험 릴리스에서 이 기능은 파드 당 컨테이너 1개로 제한된다.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: iis
+spec:
+  selector:
+    matchLabels:
+      app: iis
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: iis
+      annotations:
+        experimental.windows.kubernetes.io/isolation-type: hyperv
+    spec:
+      containers:
+      - name: iis
+        image: microsoft/iis
+        ports:
+        - containerPort: 80
+```
+
+### kubeadm 및 클러스터 API를 사용한 배포
+
+Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이 
+되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만 
+[여기](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
+또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에 
+투자하고 있다.
+
+### 몇 가지 기타 주요 기능
+* 그룹 관리 서비스 어카운트(Service Accounts)에 대한 베타 지원
+* 더 많은 CNI
+* 더 많은 스토리지 플러그인
+
+
@@ -19,7 +19,7 @@ weight: 75

 ## 시작하기 전에

-* [윈도우 서버에서 운영하는 마스터와 워커 노드](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다.
+* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다.
 * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.

 ## 시작하기: 윈도우 컨테이너 배포하기
@@ -150,7 +150,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509

 - **이미지 풀(Pull) 시크릿**:
  특정 도커 컨테이너 이미지가 프라이빗한 경우,
-  [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 자격 증명을 요구한다.
+  [풀(Pull) 시크릿](/ko/docs/concepts/configuration/secret/) 자격 증명을 요구한다.

  대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다.
  시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다.
@@ -6,6 +6,7 @@ content_type: task
 <!-- overview -->
 이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다.

+{{% thirdparty-content %}}

 ## {{% heading "prerequisites" %}}

@@ -20,11 +21,6 @@ content_type: task
 * [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
 * [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)

-{{< note >}}
-위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다.
-{{< /note >}}
-
-
 <!-- steps -->

 ## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기
@@ -63,7 +59,7 @@ NAME                        READY         STATUS        RESTARTS   AGE
 pod/nginx-701339712-e0qfq   1/1           Running       0          35s
 ```

-## 다른 파드에서 접근하여 서비스 테스트하기 
+## 다른 파드에서 접근하여 서비스 테스트하기

 사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.

@@ -84,11 +80,11 @@ remote file exists

 ## `nginx` 서비스에 대해 접근 제한하기

-`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다. 
+`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.

 {{< codenew file="service/networking/nginx-policy.yaml" >}}

-네트워크폴리시 오브젝트의 이름은 유효한 
+네트워크폴리시 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.

 {{< note >}}
@@ -155,7 +155,7 @@ min-kubernetes-server-version: 1.19
 {{< note >}}
 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다.
 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다.
-자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
+자세한 내용은 [인증서 관리 가이드](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
 {{</ note >}}

 {{< note >}}
@@ -0,0 +1,287 @@
+---
+title: 스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정하기
+content_type: task
+weight: 60
+---
+
+<!-- overview -->
+
+이 페이지는 스토리지에 대해
+{{< glossary_tooltip text="퍼시스턴트볼륨클레임(PersistentVolumeClaim)" term_id="persistent-volume-claim" >}}을
+사용하도록 파드를 설정하는 방법을 보여준다.
+과정의 요약은 다음과 같다.
+
+1. 클러스터 관리자로서, 물리적 스토리지와 연결되는 퍼시스턴트볼륨을 
+생성한다. 볼륨을 특정 파드와 연결하지 않는다.
+
+1. 그 다음 개발자 / 클러스터 사용자의 역할로서, 적합한 
+퍼시스턴트볼륨에 자동으로 바인딩되는 퍼시스턴트볼륨클레임을 
+생성한다.
+
+1. 스토리지에 대해 위의 퍼시스턴트볼륨클레임을 사용하는 파드를 생성한다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+* 사용자는 노드가 단 하나만 있는 쿠버네티스 클러스터가 필요하고,
+{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
+커맨드라인 툴이 사용자의 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약 사용자가 
+아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/setup/learning-environment/minikube/)를 
+사용하여 클러스터 하나를 생성할 수 있다.
+
+* [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)의 
+관련 자료에 익숙해지도록 한다.
+
+<!-- steps -->
+
+## 사용자 노드에 index.html 파일 생성하기
+
+사용자 클러스터의 단일 노드에 연결되는 셸을 연다. 셸을 여는 방법은 
+클러스터 설정에 따라 달라진다. 예를 들어 Minikube를 사용하는 경우, 
+`minikube ssh` 명령어를 입력하여 노드로 연결되는 셸을 열 수 있다. 
+
+해당 노드의 셸에서 `/mnt/data` 디렉터리를 생성한다.
+
+```shell
+# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
+# "sudo"를 사용한다고 가정한다
+sudo mkdir /mnt/data
+```
+
+
+`/mnt/data` 디렉터리에서 `index.html` 파일을 생성한다.
+
+```shell
+# 이번에도 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
+# "sudo"를 사용한다고 가정한다
+sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
+```
+
+{{< note >}}
+사용자 노드에서 `sudo` 이외의 슈퍼유저 접근 툴을 사용하는 경우,
+`sudo` 를 해당 툴의 이름으로 바꾸면, 동일하게 작업을 수행할 수 있다.
+{{< /note >}}
+
+`index.html` 파일이 존재하는지 테스트한다.
+
+```shell
+cat /mnt/data/index.html
+```
+
+결과는 다음과 같다.
+```
+Hello from Kubernetes storage
+```
+
+이제 사용자 노드에서 셸을 종료해도 된다.
+
+## 퍼시스턴트볼륨 생성하기
+
+이 예제에서, 사용자는 *hostPath* 퍼시스턴트볼륨을 생성한다. 쿠버네티스는 단일 노드에서의 
+개발과 테스트를 위해 hostPath를 지원한다. hostPath 퍼시스턴트볼륨은 
+네트워크로 연결된 스토리지를 모방하기 위해, 노드의 파일이나 디렉터리를 사용한다.
+
+운영 클러스터에서, 사용자가 hostPath를 사용하지는 않는다. 대신, 클러스터 관리자는 
+Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic 
+Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는 
+[스토리지클래스(StorageClasses)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)를 
+사용하여 
+[동적 프로비저닝](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)을 설정할 수도 있다. 
+
+hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다.
+
+{{< codenew file="pods/storage/pv-volume.yaml" >}}
+
+설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고
+지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
+읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를
+지정한다. 여기서는 
+퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 
+`manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 
+이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
+
+퍼시스턴트볼륨을 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
+```
+
+퍼시스턴트볼륨에 대한 정보를 조회한다.
+
+```shell
+kubectl get pv task-pv-volume
+```
+
+결과는 퍼시스턴트볼륨의 `STATUS` 가 `Available` 임을 보여준다. 이는 
+아직 퍼시스턴트볼륨클레임이 바인딩되지 않았다는 것을 의미한다.
+
+    NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
+    task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s
+
+## 퍼시스턴트볼륨클레임 생성하기
+
+다음 단계는 퍼시스턴트볼륨클레임을 생성하는 단계이다. 파드는 퍼시스턴트볼륨클레임을 
+사용하여 물리적인 스토리지를 요청한다. 이 예제에서, 사용자는 적어도 
+하나 이상의 노드에 대해 읽기-쓰기 접근을 지원하며 최소 3 기가바이트의 볼륨을 요청하는
+퍼시스턴트볼륨클레임을 생성한다.
+
+퍼시스턴트볼륨클레임에 대한 설정 파일은 다음과 같다.
+
+{{< codenew file="pods/storage/pv-claim.yaml" >}}
+
+퍼시스턴트볼륨클레임을 생성한다.
+
+    kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
+
+사용자가 퍼시스턴트볼륨클레임을 생성한 후에, 쿠버네티스 컨트롤 플레인은 
+클레임의 요구사항을 만족하는 퍼시스턴트볼륨을 찾는다. 컨트롤 플레인이 
+동일한 스토리지클래스를 갖는 적절한 퍼시스턴트볼륨을 찾으면, 
+볼륨에 클레임을 바인딩한다.
+
+퍼시스턴트볼륨을 다시 확인한다.
+
+```shell
+kubectl get pv task-pv-volume
+```
+
+이제 결과는 `STATUS` 가 `Bound` 임을 보여준다.
+
+    NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
+    task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m
+
+퍼시스턴트볼륨클레임을 확인한다.
+
+```shell
+kubectl get pvc task-pv-claim
+```
+
+결과는 퍼시스턴트볼륨클레임이 사용자의 퍼시스턴트볼륨인 `task-pv-volume` 에 
+바인딩되어 있음을 보여준다.
+
+    NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
+    task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s
+
+## 파드 생성하기
+
+다음 단계는 볼륨으로 퍼시스턴트볼륨클레임을 사용하는 파드를 만드는 단계이다.
+
+파드에 대한 설정 파일은 다음과 같다.
+
+{{< codenew file="pods/storage/pv-pod.yaml" >}}
+
+파드의 설정 파일은 퍼시스턴트볼륨클레임을 지정하지만, 
+퍼시스턴트볼륨을 지정하지는 않는다는 것을 유념하자. 파드의 관점에서 볼때, 
+클레임은 볼륨이다.
+
+파드를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
+```
+
+파드의 컨테이너가 실행 중임을 확인한다.
+
+```shell
+kubectl get pod task-pv-pod
+```
+
+사용자 파드에서 구동되고 있는 컨테이너에 셸로 접근한다.
+
+```shell
+kubectl exec -it task-pv-pod -- /bin/bash
+```
+
+사용자의 셸에서, nginx가 hostPath 볼륨으로부터 `index.html` 파일을 
+제공하는지 확인한다.
+
+```shell
+# 이전 단계에서 "kubectl exec" 명령을 실행한 root 셸 안에서 
+# 다음의 3개 명령을 실행해야 한다.
+apt update
+apt install curl
+curl http://localhost/
+```
+
+결과는 hostPath 볼륨에 있는 `index.html` 파일에 사용자가 작성한 텍스트를
+보여준다.
+
+    Hello from Kubernetes storage
+
+
+만약 사용자가 위와 같은 메시지를 확인하면, 파드가 퍼시스턴트볼륨클레임의 스토리지를 
+사용하도록 성공적으로 설정한 것이다.
+
+## 정리하기
+
+파드, 퍼시스턴트볼륨클레임, 퍼시스턴트볼륨을 삭제한다.
+
+```shell
+kubectl delete pod task-pv-pod
+kubectl delete pvc task-pv-claim
+kubectl delete pv task-pv-volume
+```
+
+만약 클러스터의 노드에 대한 셸이 열려져 있지 않은 경우, 
+이전과 동일한 방식으로 새로운 셸을 연다.
+
+사용자 노드의 셸에서, 생성한 파일과 디렉터리를 제거한다.
+
+```shell
+# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
+# "sudo"를 사용한다고 가정한다
+sudo rm /mnt/data/index.html
+sudo rmdir /mnt/data
+```
+
+이제 사용자 노드에서 셸을 종료해도 된다.
+
+
+
+
+<!-- discussion -->
+
+## 접근 제어
+
+그룹 ID(GID)로 설정된 스토리지는 동일한 GID를 사용하는 파드에서만 쓰기 
+작업을 허용한다. GID가 일치하지 않거나 누락되었을 경우 권한 
+거부 오류가 발생한다. 사용자와의 조정 필요성을 줄이기 위하여 관리자는 
+퍼시스턴트 볼륨에 GID로 어노테이션을 달 수 있다. 그 뒤에, 퍼시스턴트볼륨을 
+사용하는 모든 파드에 대하여 GID가 자동으로 추가된다.
+
+다음과 같이 `pv.beta.kubernetes.io/gid` 어노테이션을 사용한다.
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv1
+  annotations:
+    pv.beta.kubernetes.io/gid: "1234"
+```
+파드가 GID 어노테이션이 있는 퍼시스턴트볼륨을 사용하면, 어노테이션으로
+달린 GID가 파드의 보안 컨텍스트에 지정된 GID와 동일한 방식으로
+파드의 모든 컨테이너에 적용된다. 파드의 명세 혹은 퍼시스턴트볼륨의
+어노테이션으로부터 생성된 모든 GID는, 각 컨테이너에서 실행되는 첫 번째
+프로세스에 적용된다.
+
+{{< note >}}
+파드가 퍼시스턴트볼륨을 사용할 때, 퍼시스턴트볼륨과 연관된 
+GID는 파드 리소스 자체에는 존재하지 않는다.
+{{< /note >}}
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기.
+* [퍼시스턴트 스토리지 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)에 대해 읽어보기.
+
+### Reference
+
+* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
+* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
+* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
+* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
@@ -206,7 +206,7 @@ kubectl get pod private-reg
 ## {{% heading "whatsnext" %}}


-* [시크릿](/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
+* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
 * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
 * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
@@ -0,0 +1,103 @@
+---
+title: 파드와 레플리케이션컨트롤러(ReplicationController) 디버그하기
+content_type: task
+---
+
+<!-- overview -->
+
+이 페이지에서는 파드와 레플리케이션컨트롤러를 디버깅하는 방법을 소개한다.
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+* 사용자는
+  {{< glossary_tooltip text="파드" term_id="pod" >}} 기본 사항과 파드의  
+  [라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 잘 알고 있어야 한다.
+
+<!-- steps -->
+
+## 파드 디버깅
+
+파드 디버깅의 첫 번째 단계는 파드를 살펴 보는 것이다. 다음의 명령어를
+사용하여 파드의 현재 상태와 최근 이벤트를 점검한다.
+
+```shell
+kubectl describe pods ${POD_NAME}
+```
+
+파드 내부 컨테이너의 상태를 확인한다. 모두 `Running` 상태인가?
+최근에 재시작 되었는가?
+
+파드의 상태에 따라 디버깅을 계속한다.
+
+### 파드가 pending 상태로 유지
+
+파드가 `Pending` 상태로 멈춰 있는 경우는, 노드에 스케줄 될 수 없음을 의미한다.
+일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다.
+상단의 `kubectl describe ...` 명령의 결과를 확인하자.
+파드를 스케줄 할 수 없는 이유에 대한 스케줄러의 메세지가 있어야 한다.
+이유는 다음과 같다.
+
+#### 부족한 리소스
+
+사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우
+몇 가지 방법을 시도할 수 있다.
+
+* 클러스터에 [노드를 더 추가하기](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-크기-재조정).
+
+* pending 상태인 파드를 위한 공간을 확보하기 위해
+  [불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
+
+* 파드가 노드보다 크지 않은지 확인한다. 예를 들어 모든
+  노드가 `cpu:1` 의 용량을 가지고 있을 경우, `cpu: 1.1` 을 요청하는 파드는
+  절대 스케줄 될 수 없다.
+
+	사용자는 `kubectl get nodes -o <format>` 명령으로 노드의
+	용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지
+	명령의 예이다.
+
+    ```shell
+    kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
+    kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
+    ```
+
+  [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)
+  기능은 사용할 수 있는 전체 리소스의 양을 제한하도록 설정할 수 있다.
+  네임스페이스와 함께 사용하면,
+  한 팀이 모든 리소스를 점유하는 것을 방지할 수 있다.
+
+#### hostPort 사용하기
+
+파드를 `hostPort` 에 바인딩 할 때 파드를 스케줄링 할 수 있는
+위치는 제한되어 있다. 대부분의 경우 `hostPort` 는 불필요하다. 서비스 오브젝트를
+사용하여 파드를 노출하도록 한다. `hostPort` 가 필요한 경우
+컨테이너 클러스터에 있는 노드의 수만큼 파드를 스케줄 할 수 있다.
+
+### 파드가 waiting 상태로 유지
+
+파드가 `Waiting` 상태에서 멈춘 경우, 워커 노드에 스케줄 되었지만, 해당 장비에서 사용할 수 없다.
+거듭 강조하지만, `kubectl describe ...` 의 정보는 유익하게 사용되어야 한다.
+`Waiting` 파드의 가장 일반적인 원인은 이미지를 가져오지 못하는 경우이다.
+확인해야 할 3가지 사항이 있다.
+
+* 이미지 이름이 올바른지 확인한다.
+* 이미지를 저장소에 푸시하였는가?
+* 이미지가 풀 될 수 있는지 보기 위해, 사용자의 장비에서 `docker pull <image>` 를 수동으로
+  실행한다.
+
+### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
+
+일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에
+기술된 메서드를 디버깅에 사용할 수 있다.
+
+
+## 레플리케이션컨트롤러 디버깅
+
+레플리케이션컨트롤러는 매우 간단하다. 이 오브젝트는 파드를 만들거나
+만들 수 없는 경우뿐이다. 만약 파드를 만들 수 없는 경우,
+[위의 지침](#파드-디버깅)을 참조하여 파드를 디버그한다.
+
+사용자는 `kubectl describe rc ${CONTROLLER_NAME}` 을 사용하여 레플리케이션 컨트롤러와
+관련된 이벤트를 검사할 수도 있다.
@@ -89,8 +89,8 @@ command: ["/bin/echo"]
 args: ["$(MESSAGE)"]
 ```

-이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure
-pod-configmap/)과 [시크릿](/docs/concepts/configuration/secret/)을
+이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)과
+[시크릿](/ko/docs/concepts/configuration/secret/)을
 포함해, 환경 변수를 정의하는데 활용할 수 있는 모든 방법들을 활용해서 파드를 위한 인자를
 정의할
 수 있다는 것을 의미한다.
@@ -0,0 +1,5 @@
+---
+title: "잡(Job) 실행"
+description: 병렬 처리를 사용하여 잡을 실행한다.
+weight: 50
+---
@@ -0,0 +1,208 @@
+---
+title: 크론잡(CronJob)으로 자동화된 작업 실행
+min-kubernetes-server-version: v1.8
+content_type: task
+weight: 10
+---
+
+<!-- overview -->
+
+시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
+이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
+
+크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
+크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
+
+크론 잡에는 제한 사항과 특이점이 있다.
+예를 들어, 특정 상황에서는 하나의 크론 잡이 여러 잡을 생성할 수 있다.
+따라서, 잡은 멱등성을 가져야 한다.
+
+제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+* {{< include "task-tutorial-prereqs.md" >}}
+
+
+
+<!-- steps -->
+
+## 크론 잡 생성
+
+크론 잡은 구성 파일이 필요하다.
+아래의 크론 잡 구성 `.spec` 파일의 예제는 매 분마다 현재 시간과 hello 메시지를 출력한다.
+
+{{< codenew file="application/job/cronjob.yaml" >}}
+
+다음 명령을 사용하여 크론잡 예제를 실행한다.
+
+```shell
+kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml
+```
+출력 결과는 다음과 비슷하다.
+
+```
+cronjob.batch/hello created
+```
+
+크론 잡을 생성한 후, 다음 명령을 사용하여 상태를 가져온다.
+
+```shell
+kubectl get cronjob hello
+```
+출력 결과는 다음과 비슷하다.
+
+```
+NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
+hello   */1 * * * *   False     0        <none>          10s
+```
+
+명령의 결과에서 알 수 있듯이, 크론 잡은 아직 잡을 스케줄하거나 실행하지 않았다.
+약 1분 내로 잡이 생성되는지 확인한다.
+
+```shell
+kubectl get jobs --watch
+```
+출력 결과는 다음과 비슷하다.
+
+```
+NAME               COMPLETIONS   DURATION   AGE
+hello-4111706356   0/1                      0s
+hello-4111706356   0/1           0s         0s
+hello-4111706356   1/1           5s         5s
+```
+
+이제 "hello" 크론 잡에 의해 스케줄된 실행 중인 작업을 확인했다.
+잡 감시를 중지한 뒤에 크론 잡이 다시 스케줄되었는지를 확인할 수 있다.
+
+```shell
+kubectl get cronjob hello
+```
+출력 결과는 다음과 비슷하다.
+
+```
+NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
+hello   */1 * * * *   False     0        50s             75s
+```
+
+크론 잡 `hello` 가 `LAST SCHEDULE` 에 지정된 시간에 성공적으로 잡을 스케줄했는지 확인해야 한다. 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
+
+이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
+
+{{< note >}}
+잡 이름과 파드 이름은 다르다.
+{{< /note >}}
+
+```shell
+# "hello-4111706356"을 사용자의 시스템에 있는 잡 이름으로 바꾼다
+pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})
+```
+파드의 로그를 출력한다.
+
+```shell
+kubectl logs $pods
+```
+출력 결과는 다음과 비슷하다.
+
+```
+Fri Feb 22 11:02:09 UTC 2019
+Hello from the Kubernetes cluster
+```
+
+## 크론 잡 삭제
+
+더 이상 크론 잡이 필요하지 않으면, `kubectl delete cronjob <cronjob name>` 명령을 사용해서 삭제한다.
+
+```shell
+kubectl delete cronjob hello
+```
+
+크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
+[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
+
+## 크론 잡 명세 작성
+
+다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
+작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
+[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
+
+크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
+
+{{< note >}}
+크론 잡, 특히 해당 잡의 `.spec` 에 대한 모든 수정 사항은 다음 번 실행에만 적용된다.
+{{< /note >}}
+
+### 스케줄
+
+`.spec.schedule` 은 `.spec` 의 필수 필드이다.
+이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
+
+이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은
+[FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
+
+> 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/<number>` 를
+> 지정하여 범위 내에서 숫자만큼의 값을 건너뛴다. 예를 들어,
+> 시간 필드에 `0-23/2` 를 사용하여 매 2시간마다 명령 실행을
+> 지정할 수 있다(V7 표준의 대안은 `0,2,4,6,8,10,12,14,16,18,20,22`
+> 이다). 별표(asterisk) 뒤에 붙이는 스텝도 허용되며,
+> "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
+
+{{< note >}}
+스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
+{{< /note >}}
+
+### 잡 템플릿
+
+`.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
+이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
+잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
+
+### 시작 기한
+
+`.spec.startingDeadlineSeconds` 필드는 선택 사항이다.
+어떤 이유로든 스케줄된 시간을 놓친 경우 잡의 시작 기한을 초 단위로 나타낸다.
+기한이 지나면, 크론 잡이 잡을 시작하지 않는다.
+이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
+이 필드를 지정하지 않으면, 잡에 기한이 없다.
+
+크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다.
+
+예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다.
+
+`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다.
+
+예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다.
+
+### 동시성 정책
+
+`.spec.concurrencyPolicy` 필드도 선택 사항이다.
+이것은 이 크론 잡에 의해 생성된 잡의 동시 실행을 처리하는 방법을 지정한다.
+명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
+
+* `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
+* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
+* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
+
+참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
+크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
+
+### 일시 정지
+
+`.spec.suspend` 필드도 선택 사항이다.
+`true` 로 설정되면, 모든 후속 실행이 일시 정지된다.
+이 설정은 이미 시작된 실행에는 적용되지 않는다.
+기본값은 false이다.
+
+{{< caution >}}
+스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
+[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
+{{< /caution >}}
+
+### 잡 히스토리 한도
+
+`.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
+이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
+기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
@@ -0,0 +1,233 @@
+---
+title: 작업 대기열을 사용한 정밀 병렬 처리
+content_type: task
+min-kubernetes-server-version: v1.8
+weight: 40
+---
+
+<!-- overview -->
+
+이 예에서는, 지정된 파드에서 여러 병렬 워커 프로세스가 있는
+쿠버네티스 잡(Job)을 실행한다.
+
+이 예에서는, 각 파드가 생성될 때, 작업 대기열에서 하나의 작업 단위를
+선택하여, 처리하고, 대기열이 비워질 때까지 반복한다.
+
+이 예에서의 단계에 대한 개요는 다음과 같다.
+
+1. **작업 대기열을 보관할 스토리지 서비스를 시작한다.**  이 예에서는, Redis를 사용하여
+   작업 항목을 저장한다. 이전 예에서는, RabbitMQ를 사용했다. 이 예에서는, AMQP가 길이가
+   정해져 있는 작업 대기열이 비어있을 때 클라이언트가 이를 감지할 수 있는 좋은 방법을 제공하지
+   않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
+   Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
+1. **대기열을 만들고, 메시지로 채운다.**  각 메시지는 수행할 하나의 작업을 나타낸다. 이
+   예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
+1. **대기열에서 작업을 수행하는 잡을 시작한다.**  잡은 여러 파드를 시작한다. 각 파드는
+   메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+[잡](/ko/docs/concepts/workloads/controllers/job/)의 기본적이고,
+병렬 작업이 아닌, 사용법에 대해 잘 알고 있어야 한다.
+
+<!-- steps -->
+
+## Redis 시작
+
+이 문서의 예시에서는, 단순함을 위해, Redis의 단일 인스턴스를 시작한다.
+Redis를 확장 가능하고 중복적으로 배포하는 예에 대해서는
+[Redis 예시](https://github.com/kubernetes/examples/tree/master/guestbook)를 참고한다.
+
+다음 파일을 직접 다운로드할 수도 있다.
+
+- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
+- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
+- [`Dockerfile`](/examples/application/job/redis/Dockerfile)
+- [`job.yaml`](/examples/application/job/redis/job.yaml)
+- [`rediswq.py`](/examples/application/job/redis/rediswq.py)
+- [`worker.py`](/examples/application/job/redis/worker.py)
+
+
+## 작업으로 대기열 채우기
+
+이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제의 작업은 문자열을 출력하는
+것이다.
+
+Redis CLI를 실행하기 위한 임시 대화형 파드를 시작한다.
+
+```shell
+kubectl run -i --tty temp --image redis --command "/bin/sh"
+Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
+Hit enter for command prompt
+```
+
+이제 엔터 키를 누르고, redis CLI를 시작하고, 몇몇 작업 항목이 포함된 목록을 생성한다.
+
+```
+# redis-cli -h redis
+redis:6379> rpush job2 "apple"
+(integer) 1
+redis:6379> rpush job2 "banana"
+(integer) 2
+redis:6379> rpush job2 "cherry"
+(integer) 3
+redis:6379> rpush job2 "date"
+(integer) 4
+redis:6379> rpush job2 "fig"
+(integer) 5
+redis:6379> rpush job2 "grape"
+(integer) 6
+redis:6379> rpush job2 "lemon"
+(integer) 7
+redis:6379> rpush job2 "melon"
+(integer) 8
+redis:6379> rpush job2 "orange"
+(integer) 9
+redis:6379> lrange job2 0 -1
+1) "apple"
+2) "banana"
+3) "cherry"
+4) "date"
+5) "fig"
+6) "grape"
+7) "lemon"
+8) "melon"
+9) "orange"
+```
+
+자, 키 `job2` 가 있는 목록이 작업 대기열이 된다.
+
+참고: Kube DNS를 올바르게 설정하지 않은 경우, 위 블록의
+첫 번째 단계를 `redis-cli -h $REDIS_SERVICE_HOST` 로 변경해야 할 수 있다.
+
+
+## 이미지 생성
+
+이제 실행할 이미지를 만들 준비가 되었다.
+
+redis 클라이언트와 함께 python 워커 프로그램을 사용하여
+메시지 큐에서 메시지를 읽는다.
+
+rediswq.py([다운로드](/examples/application/job/redis/rediswq.py))라는
+간단한 Redis 작업 대기열 클라이언트 라이브러리가 제공된다.
+
+잡의 각 파드에 있는 "워커" 프로그램은 작업 대기열
+클라이언트 라이브러리를 사용하여 작업을 가져온다. 다음은 워커 프로그램이다.
+
+{{< codenew language="python" file="application/job/redis/worker.py" >}}
+
+[`worker.py`](/examples/application/job/redis/worker.py),
+[`rediswq.py`](/examples/application/job/redis/rediswq.py) 및
+[`Dockerfile`](/examples/application/job/redis/Dockerfile) 파일을 다운로드할 수 있고, 그런 다음
+이미지를 만들 수도 있다.
+
+```shell
+docker build -t job-wq-2 .
+```
+
+### 이미지 푸시
+
+[도커 허브(Docker Hub)](https://hub.docker.com/)를 위해, 아래 명령으로
+사용자의 username과 앱 이미지에 태그하고 허브에 푸시한다. `<username>` 을
+사용자의 허브 username으로 바꾼다.
+
+```shell
+docker tag job-wq-2 <username>/job-wq-2
+docker push <username>/job-wq-2
+```
+
+공용 저장소로 푸시하거나 [개인 저장소에 접근할 수 있도록
+클러스터를 구성](/ko/docs/concepts/containers/images/)해야 한다.
+
+[Google Container
+Registry](https://cloud.google.com/tools/container-registry/)를 사용하는 경우,
+사용자의 프로젝트 ID로 앱 이미지에 태그를 지정하고 GCR로 푸시한다. `<project>` 를
+사용자의 프로젝트 ID로 바꾼다.
+
+```shell
+docker tag job-wq-2 gcr.io/<project>/job-wq-2
+gcloud docker -- push gcr.io/<project>/job-wq-2
+```
+
+## 잡 정의
+
+다음은 잡 정의이다.
+
+{{< codenew file="application/job/redis/job.yaml" >}}
+
+사용자 자신의 경로로 `gcr.io/myproject` 를
+변경하려면 잡 템플릿을 편집해야 한다.
+
+이 예에서, 각 파드는 대기열의 여러 항목에 대해 작업한 다음 더 이상 항목이 없을 때 종료된다.
+워커는 작업 대기열이 비어있을 때를 감지하고 잡 컨트롤러는 작업 대기열에 대해
+알지 못하기 때문에, 작업이 완료되면 워커에게 신호를 보낸다.
+워커는 성공적으로 종료하여 대기열이 비어 있음을 알린다. 따라서, 워커가 성공적으로
+종료하자마자, 컨트롤러는 작업이 완료되었음을 인식하고, 파드가 곧 종료된다.
+따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
+기다린다.
+
+## 잡 실행
+
+이제 잡을 실행한다.
+
+```shell
+kubectl apply -f ./job.yaml
+```
+
+이제 조금 기다린 다음, 잡을 확인한다.
+
+```shell
+kubectl describe jobs/job-wq-2
+Name:             job-wq-2
+Namespace:        default
+Selector:         controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+Labels:           controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+                  job-name=job-wq-2
+Annotations:      <none>
+Parallelism:      2
+Completions:      <unset>
+Start Time:       Mon, 11 Jan 2016 17:07:59 -0800
+Pods Statuses:    1 Running / 0 Succeeded / 0 Failed
+Pod Template:
+  Labels:       controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+                job-name=job-wq-2
+  Containers:
+   c:
+    Image:              gcr.io/exampleproject/job-wq-2
+    Port:
+    Environment:        <none>
+    Mounts:             <none>
+  Volumes:              <none>
+Events:
+  FirstSeen    LastSeen    Count    From            SubobjectPath    Type        Reason            Message
+  ---------    --------    -----    ----            -------------    --------    ------            -------
+  33s          33s         1        {job-controller }                Normal      SuccessfulCreate  Created pod: job-wq-2-lglf8
+
+
+kubectl logs pods/job-wq-2-7r7b2
+Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
+Initial queue state: empty=False
+Working on banana
+Working on date
+Working on lemon
+```
+
+보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
+
+<!-- discussion -->
+
+## 대안
+
+대기열 서비스를 실행하거나 작업 대기열을 사용하도록 컨테이너를 수정하는 것이 불편한 경우, 다른
+[잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)
+중 하나를 고려할 수 있다.
+
+만약 실행할 백그라운드 처리 작업의 연속 스트림이 있는 경우,
+`ReplicaSet` 이 있는 백그라운드 워커를 실행하는 것과,
+[https://github.com/resque/resque](https://github.com/resque/resque)와 같은
+백그라운드 처리 라이브러리를 실행하는 것이 좋다.
@@ -13,7 +13,6 @@ content_type: task

 * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
 * 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)  (예. Kubenet 또는 Calico)
-* IPVS 모드로 구동되는 Kube-proxy
 * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터

 {{< version-check >}}
@@ -47,7 +47,7 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
 동적 프로비저너에 의해서 충족된다.

 참고: config yaml 파일에 정의된 비밀번호는 안전하지 않다. 더 안전한 해결방법을 위해 
-[쿠버네티스 시크릿](/docs/concepts/configuration/secret/)
+[쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
 을 보자

 {{< codenew file="application/mysql/mysql-deployment.yaml" >}}
@@ -25,10 +25,10 @@ no_list: true

 공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/)
 가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면
-[Minikube 설치](/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
+[Minikube 설치](/ko/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.

 Minikube가 작동하면, 이를 사용하여
-[샘플 애플리케이션을 실행](/docs/tutorials/hello-minikube/)해볼 수 있다.
+[샘플 애플리케이션을 실행](/ko/docs/tutorials/hello-minikube/)해볼 수 있다.

 ## kind

@@ -523,7 +523,7 @@ compinit

 * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/)
 * 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다.
-* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
 * 직접 생성하지 않은 클러스터에 접근해야하는 경우,
  [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
 * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기
@@ -21,10 +21,7 @@ weight: 20
            <div class="katacoda__alert">
                화면이 너무 좁아 터미널과 상호작용할 수 없습니다. 데스크톱/태블릿을 사용해주세요.
            </div>
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/1"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
        </div>
        <div class="row">
            <div class="col-md-12">
@@ -31,10 +31,7 @@ weight: 20
                터미널로 상호 작용하기 위해서, 데스크탑/태블릿 버전을 사용해주세요
            </div>

-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/7"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
            </div>

        </div>
@@ -24,10 +24,7 @@ weight: 20
                터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다.
            </div>

-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/4"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
            </div>
        </div>
        <div class="row">
@@ -21,10 +21,7 @@ weight: 20
            <div class="katacoda__alert">
                터미널로 상호 작용하기 위해서, 데스크탑/태블릿 버전을 사용해주세요
            </div>
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/5"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
            </div>
        </div>
        <div class="row">
@@ -1026,7 +1026,7 @@ web-1
 다시 생성되고 `web-0`과 `web-1`은 계속
 각 호스트네임을 제공한다.

-최종적으로 `web` 스테이트풀셋을 삭제한다.
+최종적으로 `nginx` 서비스를 삭제한다.

 ```shell
 kubectl delete service nginx
@@ -1034,7 +1034,7 @@ kubectl delete service nginx
 ```
 service "nginx" deleted
 ```
-그리고 `nginx` 서비스를 삭제한다.
+그리고 `web` 스테이트풀셋을 삭제한다.
 ```shell
 kubectl delete statefulset web
 ```
@@ -2,7 +2,7 @@
 title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기"
 content_type: tutorial
 weight: 20
-card: 
+card:
  name: tutorials
  weight: 40
  title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨"
@@ -13,7 +13,7 @@ card:
 <!-- overview -->
 이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다.

-[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.
+[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/ko/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.

 {{< warning >}}
 이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자.
@@ -76,7 +76,7 @@ MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필
 ## kustomization.yaml 생성하기

 ### 시크릿 생성자 추가
-[시크릿](/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다.
+[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다.

 다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다.

@@ -98,7 +98,7 @@ EOF
 다음의 매니페스트는 단일-인스턴스 WordPress 디플로이먼트를 기술한다. WordPress 컨테이너는
 웹사이트 데이터 파일을 위해 `/var/www/html`에 퍼시스턴트볼륨을 마운트한다. `WORDPRESS_DB_HOST` 환경 변수에는
 위에서 정의한 MySQL 서비스의 이름이 설정되며, WordPress는 서비스를 통해 데이터베이스에 접근한다.
-`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다. 
+`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다.

 {{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}

@@ -107,13 +107,13 @@ EOF
      ```shell
      curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
      ```
-            
+
 2. WordPress 구성 파일을 다운로드한다.

      ```shell
      curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
      ```
-      
+
 3. 두 파일을 `kustomization.yaml`에 추가하자.

 ```shell
@@ -151,7 +151,7 @@ kubectl apply -k ./
      ```shell
      kubectl get pvc
      ```
-      
+
      {{< note >}}
      PV를 프로비저닝하고 정착(bound)시키는데 수 분이 걸릴 수 있다.
      {{< /note >}}
@@ -240,6 +240,3 @@ kubectl apply -k ./
 * [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자.
 * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
 * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
-
-
-
@@ -0,0 +1,14 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: job-wq-2
+spec:
+  parallelism: 2
+  template:
+    metadata:
+      name: job-wq-2
+    spec:
+      containers:
+      - name: c
+        image: gcr.io/myproject/job-wq-2
+      restartPolicy: OnFailure
@@ -0,0 +1,23 @@
+#!/usr/bin/env python
+
+import time
+import rediswq
+
+host="redis"
+# Uncomment next two lines if you do not have Kube-DNS working.
+# import os
+# host = os.getenv("REDIS_SERVICE_HOST")
+
+q = rediswq.RedisWQ(name="job2", host="redis")
+print("Worker with sessionID: " +  q.sessionID())
+print("Initial queue state: empty=" + str(q.empty()))
+while not q.empty():
+  item = q.lease(lease_secs=10, block=True, timeout=2) 
+  if item is not None:
+    itemstr = item.decode("utf-8")
+    print("Working on " + itemstr)
+    time.sleep(10) # Put your actual work here instead of sleep.
+    q.complete(item)
+  else:
+    print("Waiting for work")
+print("Queue empty, exiting")
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: task-pv-claim
+spec:
+  storageClassName: manual
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 3Gi
@@ -0,0 +1,20 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: task-pv-pod
+spec:
+  volumes:
+    - name: task-pv-storage
+      persistentVolumeClaim:
+        claimName: task-pv-claim
+  containers:
+    - name: task-pv-container
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: task-pv-storage
+
+
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: task-pv-volume
+  labels:
+    type: local
+spec:
+  storageClassName: manual
+  capacity:
+    storage: 10Gi
+  accessModes:
+    - ReadWriteOnce
+  hostPath:
+    path: "/mnt/data"