[ko] Update links in dev-1.26-ko.1

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

@@ -344,6 +344,6 @@ CPU 및 메모리 사용량이 낮은(몇 밀리코어 수준의 CPU와 몇 메
 
 ## {{% heading "whatsnext" %}}
 
-* [쿠버네티스 시스템 로그](/docs/concepts/cluster-administration/system-logs/) 살펴보기.
+* [쿠버네티스 시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/) 살펴보기.
 * [쿠버네티스 시스템 컴포넌트에 대한 추적(trace)](/docs/concepts/cluster-administration/system-traces/) 살펴보기.
-* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기.
+* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/ko/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기.

content/ko/docs/concepts/configuration/manage-resources-containers.md

@@ -802,7 +802,7 @@ Events:
 ## {{% heading "whatsnext" %}}
 
 * [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
-* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
+* [컨테이너와 파드에 CPU 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
 * API 레퍼런스에 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)와 
   [컨테이너 리소스 요구사항](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)이 어떻게 정의되어 있는지 확인한다.
 * XFS의 [프로젝트 쿼터](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F)에 대해 읽어보기

content/ko/docs/concepts/configuration/secret.md

@@ -40,12 +40,12 @@ API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 
 
 1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다.
 1. 시크릿에 대한 최소한의 접근 권한을 지니도록
-   [RBAC 규칙을 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/)한다.
+   [RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다.
 1. 특정 컨테이너에서만 시크릿에 접근하도록 한다.
 1. [외부 시크릿 저장소 제공 서비스를 사용하는 것을 고려](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)한다.
 
 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인은
-[쿠버네티스 시크릿에 관한 좋은 관행](/docs/concepts/security/secrets-good-practices)를 참고한다.
+[쿠버네티스 시크릿에 관한 좋은 관행](/ko/docs/concepts/security/secrets-good-practices/)를 참고한다.
 
 {{< /caution >}}
 
@@ -135,10 +135,10 @@ API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 
 만들어진 시크릿은 [불변(immutable)](#secret-immutable)만 아니라면 수정될 수 있다.
 시크릿 수정 방식은 다음과 같다.
 
-* [`kubectl` 사용하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret)
-* [설정 파일 사용하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret)
+* [`kubectl` 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret)
+* [설정 파일 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret)
 
-[Kustomize 도구](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로
+[Kustomize 도구](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로
 시크릿 내부의 데이터를 수정하는 것도 가능하지만, 이 경우 수정된 데이터를 지닌 새로운 `Secret` 오브젝트가 생성된다.
 
 시크릿을 생성한 방법이나 파드에서 시크릿이 어떻게 사용되는지에 따라,
@@ -1274,7 +1274,7 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한
 ## {{% heading "whatsnext" %}}
 
 - 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인을 원한다면
-  [쿠버네티스 시크릿을 다루는 좋은 관행들](/docs/concepts/security/secrets-good-practices)을 참고하라.
+  [쿠버네티스 시크릿을 다루는 좋은 관행들](/ko/docs/concepts/security/secrets-good-practices/)을 참고하라.
 - [`kubectl` 을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
 - [구성 파일을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
 - [kustomize를 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기

content/ko/docs/concepts/containers/_index.md

@@ -18,7 +18,7 @@ content_type: concept
 따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.
 
 쿠버네티스 클러스터에 있는 개별 {{< glossary_tooltip text="node" term_id="node" >}}는
-해당 노드에 할당된 [파드](/docs/concepts/workloads/pods/)를
+해당 노드에 할당된 [파드](/ko/docs/concepts/workloads/pods/)를
 구성하는 컨테이너들을 실행한다.
 파드 내부에 컨테이너들은 같은 노드에서 실행될 수 있도록 같은 곳에 위치하고 함께 스케줄된다.
 

content/ko/docs/concepts/containers/images.md

@@ -207,7 +207,7 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
 kubelet에서 플러그인 바이너리를 호출하여 컨테이너 이미지에 대한 레지스트리 자격증명을 동적으로 가져오도록 설정할 수 있다.
 이는 프라이빗 레지스트리에서 자격증명을 가져오는 방법 중 가장 강력하며 휘발성이 있는 방식이지만, 활성화하기 위해 kubelet 수준의 구성이 필요하다.
 
-자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다.
+자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/ko/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다.
 
 ### config.json 파일 해석 {#config-json}
 

content/ko/docs/concepts/scheduling-eviction/_index.md

@@ -29,7 +29,7 @@ no_list: true
 * [동적 리소스 할당](/docs/concepts/scheduling-eviction/dynamic-resource-allocation)
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/)
-* [파드 스케줄링 준비성(readiness)](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
+* [파드 스케줄링 준비성(readiness)](/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
 
 ## 파드 중단(disruption)
 

content/ko/docs/concepts/security/pod-security-policy.md

@@ -14,7 +14,7 @@ v1.25 버전 때 쿠버네티스에서 제거되었다.
 파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을 
 적용할 수 있다.
 
-- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
+- [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/)
 - 직접 배포하고 구성할 수 있는 서드파티 어드미션 플러그인
 
 마이그레이션에 관한 설명이 필요하다면 [파드시큐리티폴리시(PodSecurityPolicy)에서 빌트인 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp/)을 참고한다.

content/ko/docs/concepts/security/pod-security-standards.md

@@ -445,7 +445,7 @@ weight: 10
 메커니즘이 발달함에 따라, 아래와 같이 정책별로 정의가 될 것이다.
 개별 정책에 대한 시행 방식은 여기서 정의하고 있지 않는다.
 
-[**파드 시큐리티 어드미션 컨트롤러**](/docs/concepts/security/pod-security-admission/)
+[**파드 시큐리티 어드미션 컨트롤러**](/ko/docs/concepts/security/pod-security-admission/)
 
 - {{< example file="security/podsecurity-privileged.yaml" >}}특권 네임스페이스{{< /example >}}
 - {{< example file="security/podsecurity-baseline.yaml" >}}기본 네임스페이스{{< /example >}}
@@ -506,7 +506,7 @@ v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며, 
 시큐리티 프로필은 컨트롤 플레인 메커니즘으로, 시큐리티 컨텍스트의 상세 설정을 비롯하여 
 시큐리티 컨텍스트 외부의 다른 관련된 파라미터도 적용한다.
 2021년 7월부로, [파드 시큐리티 폴리시](/ko/docs/concepts/security/pod-security-policy/)는 
-내장된 [파드 시큐리티 어드미션 컨트롤러](/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다. 
+내장된 [파드 시큐리티 어드미션 컨트롤러](/ko/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다. 
 
 
 ### 샌드박스 파드는 어떠한가?

content/ko/docs/concepts/security/rbac-good-practices.md

@@ -111,7 +111,7 @@ weight: 60
 더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다.
 특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면,
 **베이스라인** 혹은 **제한된** 파드 시큐리티 스탠다드를 사용해야 한다. 
-이는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 
+이는 [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/) 
 또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.
 
 이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야 

content/ko/docs/concepts/services-networking/cluster-ip-allocation.md

@@ -144,5 +144,5 @@ pie showData
 ## {{% heading "whatsnext" %}}
 
 * [클라이언트 소스 IP 보존하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해 알아보기
-* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 알아보기
+* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)에 대해 알아보기
 * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 알아보기

content/ko/docs/concepts/services-networking/endpoint-slices.md

@@ -272,6 +272,6 @@ v1 API의 `zone` 필드로 접근할 수 있다.
 
 ## {{% heading "whatsnext" %}}
 
-* [서비스와 애플리케이션 연결하기](/docs/concepts/services-networking/connect-applications-service/) 튜토리얼을 따라하기
+* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼을 따라하기
 * [엔드포인트슬라이스 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) 를 읽어보기
 * [엔드포인트 API 레퍼런스](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) 를 읽어보기

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

@@ -197,4 +197,4 @@ spec:
 ## {{% heading "whatsnext" %}}
 
 * [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)를 읽어보기.
-* [서비스와 애플리케이션 연결하기](/docs/tutorials/services/connect-applications-service/)를 읽어보기.
+* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/)를 읽어보기.

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

@@ -64,4 +64,4 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
 
 * [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
 * [서비스 외부 트래픽 정책](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
-* [서비스와 애플리케이션 연결하기](/docs/tutorials/services/connect-applications-service/) 를 따라하기
+* [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 를 따라하기

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

@@ -153,7 +153,7 @@ spec:
 백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
 
 서비스의 기본 프로토콜은 
-[TCP](/docs/reference/networking/service-protocols/#protocol-tcp)이다. 
+[TCP](/ko/docs/reference/networking/service-protocols/#protocol-tcp)이다. 
 다른 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
 
 많은 서비스가 하나 이상의 포트를 노출해야 하기 때문에, 쿠버네티스는 서비스 오브젝트에서 다중
@@ -1187,7 +1187,7 @@ spec:
 
 특정 클라이언트로부터의 연결이 매번 동일한 파드로 전달되도록 하고 싶다면, 
 클라이언트의 IP 주소 기반으로 세션 어피니티를 구성할 수 있다. 
-더 자세한 정보는 [세션 어피니티](/docs/reference/networking/virtual-ips/#session-affinity)를 
+더 자세한 정보는 [세션 어피니티](/ko/docs/reference/networking/virtual-ips/#session-affinity)를 
 참고한다.
 
 ## API 오브젝트
@@ -1205,7 +1205,7 @@ spec:
 
 ## {{% heading "whatsnext" %}}
 
-* [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
+* [서비스와 애플리케이션 연결](/ko/docs/tutorials/services/connect-applications-service/) 알아보기
 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
 

content/ko/docs/concepts/workloads/_index.md

@@ -62,7 +62,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
 
 * [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/ko/docs/tasks/run-application/run-stateless-application-deployment/)
 * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
-  또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
+  또는 [복제된 세트](/ko/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
 * [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
 
 코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는,

content/ko/docs/concepts/workloads/controllers/job.md

@@ -265,7 +265,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
     인덱스된(Indexed) 잡과 
     {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 있다면, 잡에 속한 파드는
     DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 호스트네임을 사용할 수 있다.
-    이를 어떻게 설정하는지에 대해 궁금하다면, [파드 간 통신을 위한 잡](/docs/tasks/job/job-with-pod-to-pod-communication/)를 확인한다.
+    이를 어떻게 설정하는지에 대해 궁금하다면, [파드 간 통신을 위한 잡](/ko/docs/tasks/job/job-with-pod-to-pod-communication/)를 확인한다.
   - 컨테이너화된 태스크의 경우, 환경 변수 `JOB_COMPLETION_INDEX`에 있다.
 
   각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
@@ -505,7 +505,7 @@ spec:
 [가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/
 [정적 작업 할당을 사용한 인덱싱된 잡]: /ko/docs/tasks/job/indexed-parallel-processing-static/
 [잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/
-[파드 간 통신을 위한 잡]: /docs/tasks/job/job-with-pod-to-pod-communication/
+[파드 간 통신을 위한 잡]: /ko/docs/tasks/job/job-with-pod-to-pod-communication/
 
 ## 고급 사용법
 

content/ko/docs/concepts/workloads/controllers/statefulset.md

@@ -458,7 +458,7 @@ spec:
 * 스테이트풀셋을 사용하는 방법을 알아본다.
   * [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
   * [스테이트풀셋으로 카산드라 배포](/ko/docs/tutorials/stateful-application/cassandra/) 예제를 따라한다.
-  * [복제된 스테이트풀셋 애플리케이션 구동하기](/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
+  * [복제된 스테이트풀셋 애플리케이션 구동하기](/ko/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
   * [스테이트풀셋 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
   * [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
   * [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.

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

@@ -72,7 +72,7 @@ weight: 60
 - 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다.
 - 고가용성이 필요한 경우 애플리케이션을 복제한다.
   (복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및
-  [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
+  [스테이트풀](/ko/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
   ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
   또는 영역 간

content/ko/docs/reference/_index.md

@@ -65,7 +65,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
   * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)
 
 * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
-  [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트
+  [포트와 프로토콜](/ko/docs/reference/networking/ports-and-protocols/) 리스트
 
 ## API 설정