Tenth Korean l10n work for release 1.18

- Translate concepts/extend-kubenetes/service-catalog.md in Korean (#23233)
- Translate concepts/configuration/secret.md into Korean (#23110)
- Translate tasks/extend-kubernetes/setup-extension-api-server.md into … (#22574)
- Update outdated files in dev-1.18-ko.10 branch (#23013)

Co-authored-by: Seokho Son 
Co-authored-by: Jerry Park 
Co-authored-by: santachopa 

Author: 3 people

content/ko/docs/concepts/architecture/control-plane-node-communication.md

@@ -43,7 +43,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
 
 이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.
 
-이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/control-plane-node-communication/#ssh-터널)을
+이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
 사용한다.
 
 마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.

content/ko/docs/concepts/architecture/nodes.md

@@ -20,8 +20,6 @@ weight: 10
 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}
 그리고 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 포함된다.
 
-
-
 
 
 ## 관리
@@ -336,5 +334,5 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 * [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다.
 * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
   섹션을 읽어본다.
-* [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다.
+* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
 * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.

content/ko/docs/concepts/cluster-administration/_index.md

@@ -55,14 +55,14 @@ no_list: true
 
 * [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
 
-* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
+* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
 
 * [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
 
 ### kubelet 보안
-  * [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
+  * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
   * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
-  * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/)
+  * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
 
 ## 선택적 클러스터 서비스
 

content/ko/docs/concepts/cluster-administration/addons.md

@@ -5,35 +5,30 @@ content_type: concept
 
 
 
-
 애드온은 쿠버네티스의 기능을 확장한다.
 
 이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다.
 
 각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다.
 
-
-
-
 
 
 ## 네트워킹과 네트워크 폴리시
 
-
 * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
 * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
 * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
-* [Contiv](http://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](http://github.com/contiv)이다. [인스톨러](http://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
-* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
+* [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
+* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
 * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
 * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
-* [Romana](http://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
+* [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
 
 ## 서비스 검색

content/ko/docs/concepts/cluster-administration/cloud-providers.md

@@ -8,8 +8,6 @@ weight: 30
 이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에
 대해 설명한다.
 
-
-
 
 ### kubeadm
 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다.
@@ -45,8 +43,10 @@ controllerManager:
     mountPath: "/etc/kubernetes/cloud.conf"
 ```
 
-인-트리 클라우드 제공자는 일반적으로 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
-및 [kubelet](/docs/admin/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다.
+인-트리 클라우드 제공자는 일반적으로
+[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` 에 지정된 파일의 내용도 아래에 설명되어 있다.
 
 모든 외부 클라우드 제공자의 경우, 아래 제공자에 대한 제목 아래에 있는 개별 리포지터리의 지침을 따르거나,
@@ -358,12 +358,9 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet]
   `extraroutes` 확장을 지원하는 경우 경로를 추가할 라우터를 지정하는 데 `router-id`
   를 사용한다. 선택한 라우터는 클러스터 노드를 포함하는 프라이빗 네트워크에
   걸쳐 있어야 한다(일반적으로 하나의 노드 네트워크만 있으며, 이 값은
-  노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서 [kubenet]을 사용하는 데
-  필요하다.
-
-[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet
-
-
+  노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서
+  [kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을
+  사용하는 데 필요하다.
 
 ## OVirt
 

content/ko/docs/concepts/cluster-administration/logging.md

@@ -10,9 +10,6 @@ weight: 60
 
 그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다.
 
-
-
-
 
 
 클러스터-레벨 로깅 아키텍처는 로깅 백엔드가
@@ -132,7 +129,7 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 
 
 쿠버네티스 클러스터는 노드-레벨 로깅 에이전트를 사용하는 것이 가장 일반적이며 권장되는 방법으로, 이는 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션을 변경할 필요가 없기 때문이다. 그러나, 노드-레벨 로깅은 _애플리케이션의 표준 출력과 표준 에러에 대해서만 작동한다_ .
 
-쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/user-guide/logging/stackdriver)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다.
+쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/tasks/debug-application-cluster/logging-stackdriver/)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다.
 
 ### 로깅 에이전트와 함께 사이드카 컨테이너 사용
 
@@ -239,7 +236,7 @@ fluentd를 구성하기 위한 [컨피그맵](/docs/tasks/configure-pod-containe
 {{< note >}}
 fluentd의 구성은 이 문서의 범위를 벗어난다.
 fluentd를 구성하는 것에 대한 자세한 내용은,
-[공식 fluentd 문서](http://docs.fluentd.org/)를 참고한다.
+[공식 fluentd 문서](https://docs.fluentd.org/)를 참고한다.
 {{< /note >}}
 
 두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -8,9 +8,6 @@ weight: 40
 
 애플리케이션을 배포하고 서비스를 통해 노출했다. 이제 무엇을 해야 할까? 쿠버네티스는 확장과 업데이트를 포함하여, 애플리케이션 배포를 관리하는 데 도움이 되는 여러 도구를 제공한다. 더 자세히 설명할 기능 중에는 [구성 파일](/ko/docs/concepts/configuration/overview/)과 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)이 있다.
 
-
-
-
 
 
 ## 리소스 구성 구성하기
@@ -321,7 +318,7 @@ metadata:
 kubectl scale deployment/my-nginx --replicas=1
 ```
 ```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
 ```
 
 이제 디플로이먼트가 관리하는 파드가 하나만 있다.
@@ -354,7 +351,8 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled
 
 ### kubectl apply
 
-구성 파일 셋을 소스 제어에서 유지하는 것이 좋으며([코드로서의 구성](http://martinfowler.com/bliki/InfrastructureAsCode.html) 참조),
+구성 파일 셋을 소스 제어에서 유지하는 것이 좋으며
+([코드로서의 구성](https://martinfowler.com/bliki/InfrastructureAsCode.html) 참조),
 그렇게 하면 구성하는 리소스에 대한 코드와 함께 버전을 지정하고 유지할 수 있다.
 그런 다음, [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)를 사용하여 구성 변경 사항을 클러스터로 푸시할 수 있다.