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 <shsongist@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: santachopa <santachopa@naver.com>

content/ko/docs/setup/best-practices/cluster-large.md

@@ -17,7 +17,7 @@ weight: 20
 
 클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다.
 
-보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
+보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
 
 하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다.
 
@@ -77,7 +77,7 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된
 
 ### 애드온 자원
 
-[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](http://pr.k8s.io/10653/files)과 [#10778](http://pr.k8s.io/10778/files) 참고). 
+[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](https://pr.k8s.io/10653/files)과 [#10778](https://pr.k8s.io/10778/files) 참고).
 
 예시:
 
@@ -91,34 +91,32 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된
         memory: 200Mi
 ```
 
-힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](http://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](http://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
+힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](https://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](https://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
 
 많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라.
 
 * 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다).
-  * [InfluxDB와 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, 사이드카](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+  * [InfluxDB와 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  * [kubedns, dnsmasq, 사이드카](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
 * 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자):
-  * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
 * 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다).
-  * [ElasticSearch 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [GCP 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  * [ElasticSearch 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+  * [GCP 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
 
-힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](http://issue.k8s.io/16185)과
-[#22940](http://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, 
+힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](https://issue.k8s.io/16185)과
+[#22940](https://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면,
  힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자.
 
-애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라.
-
-[미래](http://issue.k8s.io/13048)에는 모든 클러스터 애드온의 리소스 상한을 클러스터 크기에 맞게 설정해주고 클러스터를 키우거나 줄일 때 동적으로 조절해줄 수 있기를 기대한다.
-이런 기능들에 대한 PR은 언제든 환영한다.
+애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는
+[컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라.
 
 ### 시작 시 사소한 노드 오류 허용
 
-다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고 
+다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고
 `kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다.
 현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ),
-`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다. 
+`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다.
 이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다.
 실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다.