[ko] Update outdated files in dev-1.24-ko.2 (M27-M30)

content/ko/docs/concepts/security/controlling-access.md

@@ -1,9 +1,10 @@
 ---
-
-
-
+# reviewers:
+# - erictune
+# - lavalamp
 title: 쿠버네티스 API 접근 제어하기
 content_type: concept
+weight: 50
 ---
 
 <!-- overview -->
@@ -164,7 +165,27 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 
       - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
       - 인증 및 인가 모듈을 실행한다.
 
-GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
-API 서버는 포트 443에서 서비스한다.
-GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
-이외에 클러스터 설정 방법은 다양하다.
+## {{% heading "whatsnext" %}}
+
+인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
+
+- [인증하기](/docs/reference/access-authn-authz/authentication/)
+   - [부트스트랩 토큰(bootstrap token)으로 인증하기](/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [어드미션 컨트롤러(admission controller)](/docs/reference/access-authn-authz/admission-controllers/)
+   - [동적 어드미션(admission) 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [인가](/ko/docs/reference/access-authn-authz/authorization/)
+   - [역할 기반 접근 제어(role based access control)](/docs/reference/access-authn-authz/rbac/)
+   - [속성 기반 접근 제어(attribute based access control)](/docs/reference/access-authn-authz/abac/)
+   - [노드 인가](/docs/reference/access-authn-authz/node/)
+   - [웹훅(webhook) 인가](/docs/reference/access-authn-authz/webhook/)
+- [인증서 서명 요청(Certificate Signing Request)](/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) 및
+     [인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) 포함하기
+- 서비스 어카운트
+  - [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
+  - [운영](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
+
+또한, 다음 사항을 익힐 수 있다.
+- 파드가 API 크리덴셜(credential)을 얻기 위해
+  [시크릿(Secret)](/ko/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
+  을 사용하는 방법.

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

@@ -7,26 +7,25 @@ description: >
 
 ## 쿠버네티스 네트워크 모델
 
-모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 
+클러스터의 모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 
 이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며 
 또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 
 이로 인해 포트 할당, 네이밍, 서비스 디스커버리, 
 [로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing), 
-애플리케이션 구성, 마이그레이션 관점에서 `파드`를 
-VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
+애플리케이션 구성, 마이그레이션 관점에서 `파드`를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고
+하위 호환성을 갖는 모델이 제시된다.
 
-쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다 
-(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
+쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다.
+(이를 통해, 의도적인 네트워크 분할 정책을 방지)
 
-   * [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
-   * 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든 
-     파드와 통신할 수 있다
+   * 파드는 NAT 없이 [노드](/ko/docs/concepts/architecture/nodes/) 상의 모든 파드와
+     통신할 수 있다.
+   * 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든 
+     파드와 통신할 수 있다.
 
-참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는 
-다음의 요구사항도 존재한다.
-
-   * 한 노드의 호스트 네트워크에 있는 파드는 
-     NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
+참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예:
+리눅스)에 대해서는, 파드가 노드의 호스트 네트워크에 연결되어 있을 때에도 파드는 여전히
+NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
 
 이 모델은 전반적으로 덜 복잡할 뿐만 아니라, 
 무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. 

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

@@ -1,7 +1,7 @@
 ---
-
-
-
+# reviewers:
+# - davidopp
+# - thockin
 title: 서비스 및 파드용 DNS
 content_type: concept
 weight: 20
@@ -226,6 +226,7 @@ DNS 정책은 파드별로 설정할 수 있다.
   확인할 수 있다.
 - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
   "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
+  - 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다.
 - "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
   모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
   아래 절인 [파드의 DNS 설정](#pod-dns-config)에서
@@ -306,7 +307,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같
 kubectl exec -it dns-example -- cat /etc/resolv.conf
 ```
 출력은 다음과 같은 형식일 것이다.
-```shell
+```
 nameserver fd00:79:30::a
 search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
 options ndots:5
@@ -323,6 +324,24 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
 쿠버네티스는 최대 32개의 탐색 도메인과 
 최대 2048자의 탐색 도메인 목록을 허용한다.
 
+## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows}
+
+- ClusterFirstWithHostNet은 윈도우 노드에서 구동 중인 파드에는 지원되지 않는다.
+  윈도우는 `.`를 포함한 모든 네임(주소)을 FQDN으로 취급하여 FQDN 해석을 생략한다.
+- 윈도우에는 여러 DNS 해석기가 사용될 수 있다. 이러한 해석기는
+  각자 조금씩 다르게 동작하므로, 네임 쿼리 해석을 위해서
+  [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
+  파워쉘(powershell) cmdlet을 사용하는 것을 추천한다.
+- 리눅스에는 DNS 접미사 목록이 있는데, 이는 네임이 완전한 주소가 아니어서 주소
+  해석에 실패한 경우 사용한다.
+  윈도우에서는 파드의 네임스페이스(예: `mydns.svc.cluster.local`)와 연계된
+  하나의 DNS 접미사만 가질 수 있다. 윈도우는 이러한 단일 접미사 통해 해석될 수 있는
+  FQDNs, 서비스, 또는 네트워크 네임을 해석할 수 있다. 예를 들어, `default`에
+  소속된 파드는 DNS 접미사 `default.svc.cluster.local`를 가진다.
+  윈도우 파드 내부에서는 `kubernetes.default.svc.cluster.local`와
+  `kubernetes`를 모두 해석할 수 있다. 그러나, 일부에만 해당(partially qualified)하는 네임(`kubernetes.default` 또는
+  `kubernetes.default.svc`)은 해석할 수 없다.
+
 ## {{% heading "whatsnext" %}}